Закат StackOverflow?
На днях один из активных контрибьюторов из топ-1% (с рейтингом 23,315) поделился данными о количестве вопросов на StackOverflow.
Приведенная им статистика последнего года показывает драматическое падение активности:
• количество новых вопросов упало на 77% с момента запуска ChatGPT;
• в декабре 2024 было задано всего 25,566 вопросов против 42,716 в декабре 2023;
• такой низкий уровень активности последний раз наблюдался в мае 2009 года.
Сам он связывает такое падение именно с появлением ChatGPT, но на самом деле проблемы существовали задолго до этого, а ChatGPT скорее стал катализатором.
Вот какие текущие проблемы выделяют пользователи StackOverflow:
1. Внутренние проблемы:
• излишне строгая модерация - много правок, закрытие вопросов без обсуждения, даже от опытных пользователей, сложная система правил и т.п.;
• токсичность сообщества по отношению к новичкам - сам не раз такое видел, но это скорее обоюдная проблема;
• проблема устаревших ответов - многие отмечают иронию ситуации: StackOverflow когда-то появился как решение проблемы устаревших ответов на форумах, а теперь сам становится источником устаревшей информации;
• некорректная маркировка вопросов как дубликатов.
2. Влияние ИИ:
• многие простые вопросы теперь решаются через ИИ-ассистентов;
• появление некачественных ИИ-ответов на платформе - это особенно было проблемой, когда только появился ChatGPT (3.5 - он в то время очень много неверных ответов и галлюцинаций выдавал), и StackOverflow даже запретили использовать его ответы под страхом бана;
• загрязнение базы знаний автоматически сгенерированным контентом - это общая проблема всего Интернета, я про это как-то писал.
3. Бизнес-модель:
• фокус на монетизации данных для обучения ИИ;
• недостаточные инвестиции в развитие сообщества, самой платформы и системы модерации;
• краткосрочная ориентация на прибыль;
• отсутствие стратегии развития в долгосрочной перспективе на фоне изменений в индустрии, особенно в свете появлении ИИ-ассистентов.
Моё мнение по поводу падения популярности ресурса противоречивое :)
В своё время я тоже там активно отвечал на вопросы, но буквально в течение нескольких месяцев после запуска проекта, быстро набив несколько тысяч очков рейтинга, который потом постепенно подрастал (сейчас ~5,700).
Так что большинство последующих проблем как контрибьютор не застал, однако видел кучу баталий на этот счёт и изменение отношения пользователей к платформе в последние годы.
С одной стороны - да, далеко не все ответы там были хороши, провоцировали копипастинг и нередко были поверхностными.
А с другой - порог вхождения для начинающих ресурс понизил довольно сильно, и кому-то помог прийти в профессию, да и для быстрого поиска точечного ответа он вполне годился.
И вообще, иметь площадку, где твою проблему тебе могут помочь решить очень крутые спецы (раньше там активно контрибьютили настоящие легенды от мира программирования), было круто.
Каковы перспективы?
• возможно, будущее за гибридными платформами, объединяющими ИИ и человеческую экспертизу;
• StackOverflow остается важным источником ответов на сложные вопросы и вопросы о новых технологиях;
• платформа может сохранить релевантность как место для вопросов, на которые ИИ пока не может дать надежный ответ.
И теперь, видимо, ИИ выходит на первое место для тех вопросов, которые раньше задавали на StackOverflow.
—
📚 Серия постов для разработчиков по старту работы с AI
—
#ai@etechlead #development@etechlead
На днях один из активных контрибьюторов из топ-1% (с рейтингом 23,315) поделился данными о количестве вопросов на StackOverflow.
Приведенная им статистика последнего года показывает драматическое падение активности:
• количество новых вопросов упало на 77% с момента запуска ChatGPT;
• в декабре 2024 было задано всего 25,566 вопросов против 42,716 в декабре 2023;
• такой низкий уровень активности последний раз наблюдался в мае 2009 года.
Сам он связывает такое падение именно с появлением ChatGPT, но на самом деле проблемы существовали задолго до этого, а ChatGPT скорее стал катализатором.
Вот какие текущие проблемы выделяют пользователи StackOverflow:
1. Внутренние проблемы:
• излишне строгая модерация - много правок, закрытие вопросов без обсуждения, даже от опытных пользователей, сложная система правил и т.п.;
• токсичность сообщества по отношению к новичкам - сам не раз такое видел, но это скорее обоюдная проблема;
• проблема устаревших ответов - многие отмечают иронию ситуации: StackOverflow когда-то появился как решение проблемы устаревших ответов на форумах, а теперь сам становится источником устаревшей информации;
• некорректная маркировка вопросов как дубликатов.
2. Влияние ИИ:
• многие простые вопросы теперь решаются через ИИ-ассистентов;
• появление некачественных ИИ-ответов на платформе - это особенно было проблемой, когда только появился ChatGPT (3.5 - он в то время очень много неверных ответов и галлюцинаций выдавал), и StackOverflow даже запретили использовать его ответы под страхом бана;
• загрязнение базы знаний автоматически сгенерированным контентом - это общая проблема всего Интернета, я про это как-то писал.
3. Бизнес-модель:
• фокус на монетизации данных для обучения ИИ;
• недостаточные инвестиции в развитие сообщества, самой платформы и системы модерации;
• краткосрочная ориентация на прибыль;
• отсутствие стратегии развития в долгосрочной перспективе на фоне изменений в индустрии, особенно в свете появлении ИИ-ассистентов.
Моё мнение по поводу падения популярности ресурса противоречивое :)
В своё время я тоже там активно отвечал на вопросы, но буквально в течение нескольких месяцев после запуска проекта, быстро набив несколько тысяч очков рейтинга, который потом постепенно подрастал (сейчас ~5,700).
Так что большинство последующих проблем как контрибьютор не застал, однако видел кучу баталий на этот счёт и изменение отношения пользователей к платформе в последние годы.
С одной стороны - да, далеко не все ответы там были хороши, провоцировали копипастинг и нередко были поверхностными.
А с другой - порог вхождения для начинающих ресурс понизил довольно сильно, и кому-то помог прийти в профессию, да и для быстрого поиска точечного ответа он вполне годился.
И вообще, иметь площадку, где твою проблему тебе могут помочь решить очень крутые спецы (раньше там активно контрибьютили настоящие легенды от мира программирования), было круто.
Каковы перспективы?
• возможно, будущее за гибридными платформами, объединяющими ИИ и человеческую экспертизу;
• StackOverflow остается важным источником ответов на сложные вопросы и вопросы о новых технологиях;
• платформа может сохранить релевантность как место для вопросов, на которые ИИ пока не может дать надежный ответ.
И теперь, видимо, ИИ выходит на первое место для тех вопросов, которые раньше задавали на StackOverflow.
—
📚 Серия постов для разработчиков по старту работы с AI
—
#ai@etechlead #development@etechlead
👍7🔥5😢2
Вроде уже давно работаю с Cursor, но всё-таки иногда удивляет то, что они с Sonnet в агентском режиме могут выкинуть.
tl;dr
Cursor, не сумев воспользоваться готовыми картинками для теста скрипта сравнения картинок, "нарисовал" свои в html, запустил браузер, сделал скриншоты этих страниц, и использовал скриншоты в качестве тестовых картинок. И всё за один запуск Composer Agent
Дебажу тут консольный скрипт сравнения картинок, принимающий пути к двум картинкам (и пути довольно длинные).
А у интеграции Cursor с Powershell есть какой-то глюк, что если команда длинная и переносится в терминале, то выполнится только первая ее строка - это и послужило причиной всего, что началось :)
1.
* Cursor пытается запустить скрипт с путями к картинкам, но у него не получается из-за того, что команда слишком длинная
* после нескольких попыток решает, что виноваты длинные пути к файлам, и "я пойду другим, коротким путём для тестирования"
2.
* создаёт отдельную тестовую директорию с коротким названием и пытается туда скопировать одну из картинок, дав её файлу короткое имя
* снова обламывается, т.к. путь даже к одному исходному файлу оказывается слишком длинным
3.
* ладно, говорит, тут у тебя какая-то неведомая фигня с длинными путями и Powershell, давай я тестовые картинки сам сделаю
🍿 время попкорна
* иии... начинает писать html-код:
... я даже не сразу понял, что происходит, какие картинки, какой html, какая блоха
* а он сохраняет этот html в файл, потом делает еще один html, отличающийся цветом и шириной блока, и сохраняет в другой файл
4.
* в проекте есть Playwright (фреймворк для автотестов), и Cursor знает об этом
* так что он пишет временный скрипт, который с помощью Playwright открывает браузер, загружает в нём созданные html файлы и делает скриншоты страниц!
5.
* потом запускает этот скрипт и вот у нас теперь есть 2 картинки с чуть разными по цвету и размерам прямоугольниками
* наконец, успешно запускает скрипт сравнения картинок и рапортует о результатах
Всё это происходило в рамках одного запуска Composer Agent - я просто пожаловался на баг в скрипте, и понеслось.
В общем, будущее обещает быть весьма интересным, если у нас тут такое настоящее уже :)
—
📚 Серия постов для разработчиков по старту работы с AI
—
#ai@etechlead #development@etechlead
tl;dr
Дебажу тут консольный скрипт сравнения картинок, принимающий пути к двум картинкам (и пути довольно длинные).
А у интеграции Cursor с Powershell есть какой-то глюк, что если команда длинная и переносится в терминале, то выполнится только первая ее строка - это и послужило причиной всего, что началось :)
1.
* Cursor пытается запустить скрипт с путями к картинкам, но у него не получается из-за того, что команда слишком длинная
* после нескольких попыток решает, что виноваты длинные пути к файлам, и "я пойду другим, коротким путём для тестирования"
2.
* создаёт отдельную тестовую директорию с коротким названием и пытается туда скопировать одну из картинок, дав её файлу короткое имя
* снова обламывается, т.к. путь даже к одному исходному файлу оказывается слишком длинным
3.
* ладно, говорит, тут у тебя какая-то неведомая фигня с длинными путями и Powershell, давай я тестовые картинки сам сделаю
🍿 время попкорна
* иии... начинает писать html-код:
<!DOCTYPE html>
<html>
<head>
<title>Test Image 1</title>
<style>
body {
margin: 0;
padding: 20px;
background: white;
}
.box {
width: 100px;
height: 100px;
background: blue;
margin: 10px;
}
</style>
</head>
<body>
<div class="box"></div>
</body>
</html>
... я даже не сразу понял, что происходит, какие картинки, какой html, какая блоха
* а он сохраняет этот html в файл, потом делает еще один html, отличающийся цветом и шириной блока, и сохраняет в другой файл
4.
* в проекте есть Playwright (фреймворк для автотестов), и Cursor знает об этом
* так что он пишет временный скрипт, который с помощью Playwright открывает браузер, загружает в нём созданные html файлы и делает скриншоты страниц!
5.
* потом запускает этот скрипт и вот у нас теперь есть 2 картинки с чуть разными по цвету и размерам прямоугольниками
* наконец, успешно запускает скрипт сравнения картинок и рапортует о результатах
Всё это происходило в рамках одного запуска Composer Agent - я просто пожаловался на баг в скрипте, и понеслось.
В общем, будущее обещает быть весьма интересным, если у нас тут такое настоящее уже :)
—
📚 Серия постов для разработчиков по старту работы с AI
—
#ai@etechlead #development@etechlead
🔥15👍9✍2
Разбор статьи про внедрение ИИ в R&D лабе (3/3)
Личные выводы
Я вижу в этой статье много аналогий тому, что уже происходит или будет происходить в сфере разработки ПО, и этот пост об этих аналогиях.
Если вкратце - при правильном подходе писать код с ИИ и делать проекты можно в несколько раз быстрее.
Для развёрнутого примера сошлюсь на себя же.
Тут и да, и нет - с одной стороны, на типовой вопрос вам ИИ даст типовой ответ, а с другой стороны - нам вместо лишнего креатива в коде нужны надёжные проверенные решения :)
Если же запрос у нас не совсем типовой - стоит его обсуждать с моделями-ризонерами (DeepSeek R1, ChatGPT o1).
У топовых моделей также шире те знания, которые могут быть ими перенесены между языками/платформами, что позволяет выуживать из них нестандартные решения.
Рассчитывать на креатив, впрочем, не приходится, но синтез довольно интересным бывает.
Именно условные сеньоры/техлиды больше всего получают выгоды от работы с ИИ, и именно их продуктивность может вырасти в 10x+ раз за счёт того, что они могут верно выбрать направление и оценить решения, которые принимает ИИ.
Плюс, грядёт новая эра интеллектуального неравенства, и для тех кто хочет развиваться, есть куча возможностей.
Да, мне нравится давать ссылки на самого себя: при работе с ИИ пропадает часть задач и освобождается время на другие, которые уже могут быть и не связаны с программированием (что не всегда плохо, как по мне).
Легко могу себе представить фрустрацию разработчиков, которые любят именно писать код, но я не смогу их утешить, увы, - индустрия радикально изменится, и мне бы очень не хотелось, чтобы талантливые ребята, способные развиваться, оказались в позиции разработчиков-староверов.
Наблюдал такое уже не раз - человек отнекивается и не верит, пока не покажешь ему эффективный подход для работы с ИИ, после чего - эйфория (я столько всего сделаю!) вперемешку с отчаянием (я больше не нужен!), потом понимание ограничений, отрезвление и осознанное включение нового инструментария в работу по месту, а не как придётся.
И да, аугментация, усиление себя при помощи ИИ, делегируя ему посильные задачи - это то, к чему нужно стремиться для повышения своей ценности на меняющемся рынке труда.
Есть подозрение, что спрос на разработчиков-автоматизаторов нового поколения только возрастёт.
Новые технологии всегда требуют времени на их изучение, и смена привычек и устоявшихся подходов тоже не происходит мгновенно.
В случае с ИИ разработчикам нужно ещё и менять mindset: переходить на более высокий уровень абстракции, учиться ставить и делегировать задачи, проверять их исполнение, брать задачи из смежных областей - словом, становиться кем-то между архитектором и project-менеджером, со способностью иногда покодить.
И чем раньше начать, тем проще будет в дальнейшем.
—
📚 Моя серия постов для разработчиков по старту работы с AI в начале 2025 всё ещё актуальна и я буду рад, если эти знания кому-то помогут.
Фидбек тоже приветствуется :)
—
#ai #article #work #development
Личные выводы
Я вижу в этой статье много аналогий тому, что уже происходит или будет происходить в сфере разработки ПО, и этот пост об этих аналогиях.
Общее повышение продуктивности
Если вкратце - при правильном подходе писать код с ИИ и делать проекты можно в несколько раз быстрее.
Для развёрнутого примера сошлюсь на себя же.
Отсутствие "эффекта уличного фонаря": опасения, что ИИ будет направлять поиск в уже изученные, но малоперспективные области, не подтверждаются
Тут и да, и нет - с одной стороны, на типовой вопрос вам ИИ даст типовой ответ, а с другой стороны - нам вместо лишнего креатива в коде нужны надёжные проверенные решения :)
Если же запрос у нас не совсем типовой - стоит его обсуждать с моделями-ризонерами (DeepSeek R1, ChatGPT o1).
У топовых моделей также шире те знания, которые могут быть ими перенесены между языками/платформами, что позволяет выуживать из них нестандартные решения.
Рассчитывать на креатив, впрочем, не приходится, но синтез довольно интересным бывает.
ИИ не является "уравнивающим" инструментом - напротив, он усиливает различия между учеными, и это подчеркивает важность экспертизы в эпоху ИИ
Именно условные сеньоры/техлиды больше всего получают выгоды от работы с ИИ, и именно их продуктивность может вырасти в 10x+ раз за счёт того, что они могут верно выбрать направление и оценить решения, которые принимает ИИ.
Плюс, грядёт новая эра интеллектуального неравенства, и для тех кто хочет развиваться, есть куча возможностей.
Перераспределение рабочего времени на разные задачи после внедрения ИИ
Да, мне нравится давать ссылки на самого себя: при работе с ИИ пропадает часть задач и освобождается время на другие, которые уже могут быть и не связаны с программированием (что не всегда плохо, как по мне).
Значительное снижение удовлетворенности своей работой после внедрения ИИ.
Инструмент, с которым работали ученые, автоматизирует именно те задачи, которые они находят наиболее увлекательными - создание идей для новых материалов
Легко могу себе представить фрустрацию разработчиков, которые любят именно писать код, но я не смогу их утешить, увы, - индустрия радикально изменится, и мне бы очень не хотелось, чтобы талантливые ребята, способные развиваться, оказались в позиции разработчиков-староверов.
Ученые не ожидали тех эффектов, которые были задокументированы в исследовании. Это в целом соответствует тенденции, когда эксперты в своей области недооценивают возможности ИИ.
После работы с ИИ ученые начинают более позитивно оценивать его потенциал для повышения продуктивности.
Ученые понимают, что ИИ не заменяет их полностью, но меняет характер их работы
Наблюдал такое уже не раз - человек отнекивается и не верит, пока не покажешь ему эффективный подход для работы с ИИ, после чего - эйфория (я столько всего сделаю!) вперемешку с отчаянием (я больше не нужен!), потом понимание ограничений, отрезвление и осознанное включение нового инструментария в работу по месту, а не как придётся.
И да, аугментация, усиление себя при помощи ИИ, делегируя ему посильные задачи - это то, к чему нужно стремиться для повышения своей ценности на меняющемся рынке труда.
Было нанято больше новых сотрудников, чем было уволено
Есть подозрение, что спрос на разработчиков-автоматизаторов нового поколения только возрастёт.
71% ученых планируют переобучение, чтобы лучше взаимодействовать с ИИ
Новые технологии всегда требуют времени на их изучение, и смена привычек и устоявшихся подходов тоже не происходит мгновенно.
В случае с ИИ разработчикам нужно ещё и менять mindset: переходить на более высокий уровень абстракции, учиться ставить и делегировать задачи, проверять их исполнение, брать задачи из смежных областей - словом, становиться кем-то между архитектором и project-менеджером, со способностью иногда покодить.
И чем раньше начать, тем проще будет в дальнейшем.
—
📚 Моя серия постов для разработчиков по старту работы с AI в начале 2025 всё ещё актуальна и я буду рад, если эти знания кому-то помогут.
Фидбек тоже приветствуется :)
—
#ai #article #work #development
👍9🔥5❤2
OpenAI o3-mini
Анонс, System card
Это продолжение линейки рассуждающих моделей (ризонеров) от OpenAI (предыдущими были модели o1 и o1-mini).
Вышла в 3 вариантах: o3-mini-low, o3-mini-medium и o3-mini-high.
По сути, это одна и та же модель, которая работает с разными уровнями "усердия" при рассуждениях - чем выше уровень, тем больше времени и токенов модель тратит на "обдумывание" ответа.
Разница в способностях между уровнями очень заметная - чем больше модели давать рассуждать, тем лучше она решает задачи.
В чем она лучше предшественников?
* большой прирост в производительности в задачах, связанных с наукой, математикой, программированием (STEM-like);
* существенное снижение стоимости при схожей с o1 производительности (API дешевле в 10+ раз);
* увеличенная скорость ответов - как времени до первого токена, так и последующей генерации.
Модель уже доступна в API (для Tier 3+), на сайте ChatGPT, а также в Cursor (+ Agent!).
Пройдёмся по скриншотам
1 - твит Cursor о том, что o3-mini можно пока что использовать бесплатно, но при этом их собственные разработчики всё ещё предпочитают Sonnet :)
(хехе, и я тоже, об этом ниже)
2 - бенчмарк Aider Polyglot - видно, что o3-mini-high забралась довольно высоко, но при этом стоит обратить внимание на столбец "Percent using correct edit format" - процент задач, в которых модель следовала заданному формату редактирования - по этому параметру модель выглядит не так хорошо.
3 - результаты тестирования на автономность при симуляции работы инженера-исследователя OpenAI: в этом случае модель показывает нулевые результаты - предположительно из-за того, что она плохо следовала инструкциям и путала инструменты.
Можно надеяться на то, что это будет исправлено в будущем и результаты будут намного лучше.
4 - результаты решения задач Codeforces - видно, что производительность сильно выросла, даже опережает "взрослую" o1.
5 - задачи из LiveBench на олимпиадное программирование "с нуля" и на продолжение кода частичного решения олимпиадной задачи.
Тут можно отметить 2 вещи: high-модель лучше всех и там, и там, а low-модель сильно проваливается на частичных решениях.
Личные впечатления (предварительные)
Я пока что провел с ней всего несколько часов, но позже докину новых впечатлений, если что-то поменяется.
Плюс, при работе с существующей кодовой базой я использовал модель в Cursor, и там неизвестно, какой именно её вариант подключен, а это сильно влияет на результаты.
Итак, с т.з. разработки - это модель-олимпиадник :)
Отлично решает задачи на логику, математику, алгоритмы, и если у вас в коде есть что-то, что требует работы "вглубь" и на узком участке кода - однозначно стоит её использовать, это практически лучшая модель сейчас для таких задач (именно high-версия).
А вот с задачами "вширь" справляется не так успешно:
* когда в рамках задачи нужно поправить код сразу в нескольких местах - вносит ограниченное количество изменений, ломая проект;
* не очень хорошо учитывает мелкие детали, разбросанные в разных местах кодовой базы;
* удаляет код, который не нужно удалять, в процессе внесения своих изменений;
* в Cursor Agent упорно не использует инструменты, которые легко использует тот же Sonnet;
* на архитектурных задачах тоже не так хороша, как, к примеру, R1.
Очень странно, что она фейлится на задачах, связанных со structured outputs и function calling (SO/FC) - её специально на это затачивали, судя по анонсу, но что-то пошло не так.
Так что предварительно, для повседневного кода все ещё рулит Sonnet 3.5, а o3-mini достаётся роль отличного ризонера для небольших и глубоких задач.
Что дальше?
* ждём следующей модели от Claude - мне нравится Sonnet, но сколько уже можно-то;
* ждём большой o3;
* кажется, что проблема c SO/FC - низко висящий фрукт, и её могут пофиксить довольно быстро;
* хочется выбор high/medium/low-версии в Cursor (на их форуме народ уже просит такую фичу);
* надо потратить 100 баксов в API OpenAI, чтобы добраться до Tier 3, на котором станет можно использовать o3-mini - тогда можно будет опробовать модель по API в Cline/Aider :)
#ai #news #development #model
Анонс, System card
Это продолжение линейки рассуждающих моделей (ризонеров) от OpenAI (предыдущими были модели o1 и o1-mini).
Вышла в 3 вариантах: o3-mini-low, o3-mini-medium и o3-mini-high.
По сути, это одна и та же модель, которая работает с разными уровнями "усердия" при рассуждениях - чем выше уровень, тем больше времени и токенов модель тратит на "обдумывание" ответа.
Разница в способностях между уровнями очень заметная - чем больше модели давать рассуждать, тем лучше она решает задачи.
В чем она лучше предшественников?
* большой прирост в производительности в задачах, связанных с наукой, математикой, программированием (STEM-like);
* существенное снижение стоимости при схожей с o1 производительности (API дешевле в 10+ раз);
* увеличенная скорость ответов - как времени до первого токена, так и последующей генерации.
Модель уже доступна в API (для Tier 3+), на сайте ChatGPT, а также в Cursor (+ Agent!).
Пройдёмся по скриншотам
1 - твит Cursor о том, что o3-mini можно пока что использовать бесплатно, но при этом их собственные разработчики всё ещё предпочитают Sonnet :)
(хехе, и я тоже, об этом ниже)
2 - бенчмарк Aider Polyglot - видно, что o3-mini-high забралась довольно высоко, но при этом стоит обратить внимание на столбец "Percent using correct edit format" - процент задач, в которых модель следовала заданному формату редактирования - по этому параметру модель выглядит не так хорошо.
3 - результаты тестирования на автономность при симуляции работы инженера-исследователя OpenAI: в этом случае модель показывает нулевые результаты - предположительно из-за того, что она плохо следовала инструкциям и путала инструменты.
Можно надеяться на то, что это будет исправлено в будущем и результаты будут намного лучше.
4 - результаты решения задач Codeforces - видно, что производительность сильно выросла, даже опережает "взрослую" o1.
5 - задачи из LiveBench на олимпиадное программирование "с нуля" и на продолжение кода частичного решения олимпиадной задачи.
Тут можно отметить 2 вещи: high-модель лучше всех и там, и там, а low-модель сильно проваливается на частичных решениях.
Личные впечатления (предварительные)
Я пока что провел с ней всего несколько часов, но позже докину новых впечатлений, если что-то поменяется.
Плюс, при работе с существующей кодовой базой я использовал модель в Cursor, и там неизвестно, какой именно её вариант подключен, а это сильно влияет на результаты.
Итак, с т.з. разработки - это модель-олимпиадник :)
Отлично решает задачи на логику, математику, алгоритмы, и если у вас в коде есть что-то, что требует работы "вглубь" и на узком участке кода - однозначно стоит её использовать, это практически лучшая модель сейчас для таких задач (именно high-версия).
А вот с задачами "вширь" справляется не так успешно:
* когда в рамках задачи нужно поправить код сразу в нескольких местах - вносит ограниченное количество изменений, ломая проект;
* не очень хорошо учитывает мелкие детали, разбросанные в разных местах кодовой базы;
* удаляет код, который не нужно удалять, в процессе внесения своих изменений;
* в Cursor Agent упорно не использует инструменты, которые легко использует тот же Sonnet;
* на архитектурных задачах тоже не так хороша, как, к примеру, R1.
Очень странно, что она фейлится на задачах, связанных со structured outputs и function calling (SO/FC) - её специально на это затачивали, судя по анонсу, но что-то пошло не так.
Так что предварительно, для повседневного кода все ещё рулит Sonnet 3.5, а o3-mini достаётся роль отличного ризонера для небольших и глубоких задач.
Что дальше?
* ждём следующей модели от Claude - мне нравится Sonnet, но сколько уже можно-то;
* ждём большой o3;
* кажется, что проблема c SO/FC - низко висящий фрукт, и её могут пофиксить довольно быстро;
* хочется выбор high/medium/low-версии в Cursor (на их форуме народ уже просит такую фичу);
* надо потратить 100 баксов в API OpenAI, чтобы добраться до Tier 3, на котором станет можно использовать o3-mini - тогда можно будет опробовать модель по API в Cline/Aider :)
#ai #news #development #model
👍6🔥5❤1
Этихлид
при работе с существующей кодовой базой я использовал модель в Cursor, и там неизвестно, какой именно её вариант подключен
Cursor переключили с версии o3-mini-medium на o3-mini-high.
Модель явно стала умнее в подходящих для неё задачах.
Но, увы, все остальные проблемы, перечисленные в прошлом посте, остались на месте.
Больше всего неприятностей доставляет то, что она плохо работает в режиме агента и приходится многое делать (о ужас!) своими руками, за неё, включая даже проверку ошибок линтером.
Команда Cursor обещается попробовать поправить то, как они промптят модель, так что ещё посмотрим, как будет дальше.
В общем, бенчмарки-бенчмарками, но всё нужно проверять на своих рабочих задачах :)
#ai #news #development
Модель явно стала умнее в подходящих для неё задачах.
Но, увы, все остальные проблемы, перечисленные в прошлом посте, остались на месте.
Больше всего неприятностей доставляет то, что она плохо работает в режиме агента и приходится многое делать (о ужас!) своими руками, за неё, включая даже проверку ошибок линтером.
Команда Cursor обещается попробовать поправить то, как они промптят модель, так что ещё посмотрим, как будет дальше.
В общем, бенчмарки-бенчмарками, но всё нужно проверять на своих рабочих задачах :)
#ai #news #development
❤6👍3🔥3
Cursor Linter
Cursor в целом неплохой продукт, но вот с работой с сообществом и маркетингом у них прям какая-то засада.
Вот на протяжении последних нескольких релизов добавляют фичи, но при этом по-тихому, даже не всегда на своём же форуме об этом пишут.
Штош, буду иногда рассказывать о самых, на мой взгляд, полезных.
Вот, к примеру, одна из штук, которая сильно влияет на качество работы Composer Agent - это поддержка линтера.
Линтер - это либо официальная, либо сторонняя либа для разных проверок написанного кода в конкретном языке программирования.
В интересующем нас случае - для статического анализа, т.е. проверки корректности кода без его запуска.
Как работает линтер в связке с Composer Agent?
1. LLM пишет код и отдаёт Cursor'у;
2. Cursor запускает линтер локально;
3. если линтер нашел ошибки, то они передаются Cursor'ом в LLM;
4. LLM фиксит ошибки и отдаёт правки Cursor'у;
5. пункты 2-4 повторяются до тех пор, пока ошибки не будут исправлены.
В сложных случаях, бывает, участники процесса возятся довольно долго, и несколько раз я даже ловил лимит в 25 запусков тулов на один запрос в агент (это всё ещё тарифицируется как один запрос с т.з. Cursor).
За ними стоит следить - бывает, заносит с количеством правок :)
Правила для линтеров, которые использует Cursor, судя по всему, не конфигурируются, и он отлавливает только самые грубые ошибки, но даже это может уменьшить количество потенциально сломанного кода, который иногда генерит LLM.
Особенно помогает в случае статически типизированных языков (TypeScript, C#, Java, etc).
Линтеры есть практически для всех популярных языков, так что советую включить эту фичу, если по какой-то причине у вас она отключена.
#development #cursortips
Cursor в целом неплохой продукт, но вот с работой с сообществом и маркетингом у них прям какая-то засада.
Вот на протяжении последних нескольких релизов добавляют фичи, но при этом по-тихому, даже не всегда на своём же форуме об этом пишут.
Штош, буду иногда рассказывать о самых, на мой взгляд, полезных.
Вот, к примеру, одна из штук, которая сильно влияет на качество работы Composer Agent - это поддержка линтера.
Линтер - это либо официальная, либо сторонняя либа для разных проверок написанного кода в конкретном языке программирования.
В интересующем нас случае - для статического анализа, т.е. проверки корректности кода без его запуска.
Как работает линтер в связке с Composer Agent?
1. LLM пишет код и отдаёт Cursor'у;
2. Cursor запускает линтер локально;
3. если линтер нашел ошибки, то они передаются Cursor'ом в LLM;
4. LLM фиксит ошибки и отдаёт правки Cursor'у;
5. пункты 2-4 повторяются до тех пор, пока ошибки не будут исправлены.
В сложных случаях, бывает, участники процесса возятся довольно долго, и несколько раз я даже ловил лимит в 25 запусков тулов на один запрос в агент (это всё ещё тарифицируется как один запрос с т.з. Cursor).
За ними стоит следить - бывает, заносит с количеством правок :)
Правила для линтеров, которые использует Cursor, судя по всему, не конфигурируются, и он отлавливает только самые грубые ошибки, но даже это может уменьшить количество потенциально сломанного кода, который иногда генерит LLM.
Особенно помогает в случае статически типизированных языков (TypeScript, C#, Java, etc).
Линтеры есть практически для всех популярных языков, так что советую включить эту фичу, если по какой-то причине у вас она отключена.
#development #cursortips
👍8✍3🔥3
Cursor - Open search results in Composer
Бывает, что нужно какое-то изменение глобально в проекте сделать или просто в контекст закинуть все те места, где какая-то строка встречается, а по собственному RAG-индексу Cursor ищет не то, что надо.
Тогда есть вот такая штука:
1. пользуемся обычным, родным для VS Code, файловым поиском;
2. жмём на "Open search results in Composer";
3. результаты поиска в виде найденных строк и файлов, в которых они нашлись, попадают в Cursor Composer, и, соответственно, в контекст.
На скриншоте показан пример: я заранее сделал компонент для отображения статуса выполнения долгой операции, а похожий (и не всегда в точности такой же) код уже встречался в нескольких местах в проекте (результат эволюции, ну вы понимаете).
Я сделал поиск по CSS-классу, который во всех этих местах используется, передал результаты поиска в Composer и попросил заменить повторяющийся код на использование компонента.
Причем вообще не заморачивался насчет того, чтобы отфильтровать файлы по типу, убрать из результатов поиска сам компонент и т.п. - LLM достаточно умна, чтобы не творить дичь в таком простом случае.
А я ленивый :)
P.S. да, всё получилось, результат в комменте :)
#development #cursortips
Бывает, что нужно какое-то изменение глобально в проекте сделать или просто в контекст закинуть все те места, где какая-то строка встречается, а по собственному RAG-индексу Cursor ищет не то, что надо.
Тогда есть вот такая штука:
1. пользуемся обычным, родным для VS Code, файловым поиском;
2. жмём на "Open search results in Composer";
3. результаты поиска в виде найденных строк и файлов, в которых они нашлись, попадают в Cursor Composer, и, соответственно, в контекст.
На скриншоте показан пример: я заранее сделал компонент для отображения статуса выполнения долгой операции, а похожий (и не всегда в точности такой же) код уже встречался в нескольких местах в проекте (результат эволюции, ну вы понимаете).
Я сделал поиск по CSS-классу, который во всех этих местах используется, передал результаты поиска в Composer и попросил заменить повторяющийся код на использование компонента.
Причем вообще не заморачивался насчет того, чтобы отфильтровать файлы по типу, убрать из результатов поиска сам компонент и т.п. - LLM достаточно умна, чтобы не творить дичь в таком простом случае.
А я ленивый :)
P.S. да, всё получилось, результат в комменте :)
#development #cursortips
👍8🔥6
Уровни внедрения ИИ в разработку
Сейчас очень интересно наблюдать за тем, как разработка при помощи ИИ проникает в индустрию.
При этом на рынке умудряются одновременно существовать как инструменты, на добрый порядок различающиеся по своему качеству и степени автоматизации, так и разработчики, использующие эти инструменты так же на порядок (не)эффективнее.
Выделил такие уровни и практики внедрения:
0. Изоляция
Оказывается, всё ещё есть программисты, которые ничего не слышали про использование ИИ в разработке.
По этому поводу в наше время я испытываю невыразимое сочетание эмоций - это какой-то азарт антрополога, встретившего йети: хочется изучать это явление, пытаться понять, какими путями шла эволюция, как у них получается не контактировать с остальным миром... :)
1. Набегами
Использование веб-интерфейсов LLM-ок для написания небольших скриптов/функций - ну т.е. прям на сайте ChatGPT/Claude что-то конкретное просим сделать, получаем ответ, на этом общение заканчивается.
Сюда же можно отнести использование Claude Artifacts / ChatGPT Canvas для небольших прототипов.
2. Копипастинг
Разработка при помощи ИИ через копипастинг кода между каким-то UI к LLM и своей IDE.
Как по мне, это страшно неудобно, времязатратно, чревато ошибками и ускоренным износом клавиш Ctrl/C/V (ну или Ctrl/Shift/Insert, у членов древнего секретного ордена).
Однако примечательно, что тут прям целая культурно-техническая тусовка есть, которая даже придумывает штуки навроде RepoPrompt - склеивает файлы проекта в один мегафайл, чтобы было проще его копипастить туда-сюда 🤯
3. Автодополнение
Использование ИИ-автодополнения в процессе написания кода руками в своей IDE - собственно с этого всё и началось, когда вышел GitHub Copilot аж 300 лет тому назад (ну, ~3 года, если быть точнее,я был там, Гендальф).
Пользуясь случаем, ещё раз скажу, что в Cursor лучшее автодополнение кода среди всех ИИ-инструментов.
4. IDE с LLM-чатом
LLM-чат непосредственно в самой IDE - можно легко передать файлы в LLM, получить тут же ответ и применить diff к своему коду - это сейчас практически любой ИИ-плагин к IDE умеет, что делает копипастинг особенно необычной практикой.
5. IDE с LLM-агентом
Использование IDE с поддержкой агентского режима работы: Cursor / Windsurf / GitHub Copilot / (Roo)Cline.
В них можно ставить полноценные задачи, и они уже сами найдут нужный код в проекте, сами его поправят, сами выловят ошибки. Тут много нюансов и своих практик, часть которых описана мною ранее в гайде, а часть я как-нить соберусь и опишу :)
6. Агенты полного цикла
Тут у нас Devin / OpenHands - это штуки, которые способны в общем чатике типа Slack принять от вас задачу, а дальше сами зададут вопросы, сходят в Git, залезут в базу знаний проекта, напишут код, потестят его, запушат и передадут на ревью,получат зарплату.
Пока что они не готовы к реальному использованию, но это в основном проблема существующих LLM, нежели обвязки вокруг них (чем, собственно, все ИИ-инструменты для разработки и являются).
С выходом следующего поколения моделей, которое должно состояться в ближайшие несколько месяцев, тут могут быть существенные изменения.
Да и в целом, я думаю, за подобными системами будущее разработки.
7. (Secret Level)
Встречаются специальные маньяки, которые пишут свои агентские системы под задачи массовой генерации / анализа / модификации кода.
Задачи у них тоже довольно специальные, но, как правило, интересные и весьма нетривиальные.
Скорее всего позже отсюда появится свой набор инструментария для высокоуровневой работы с большими кодовыми базами.
У меня сейчас примерно такое распределение получается в задачах разработки:
* 80% - №5, Cursor Composer Agent
* 10% - №4, Cursor Chat + Cursor Composer
* 5% - №3, ручной код с автодополнением, так же в Cursor
* 5% - №1, генерация каких-то мелких скриптов через ChatGPT/DeepSeek
А как у вас обстоят дела?
Или, может, есть что-то необычное, чем можете поделиться? :)
#ai #development
Сейчас очень интересно наблюдать за тем, как разработка при помощи ИИ проникает в индустрию.
При этом на рынке умудряются одновременно существовать как инструменты, на добрый порядок различающиеся по своему качеству и степени автоматизации, так и разработчики, использующие эти инструменты так же на порядок (не)эффективнее.
Выделил такие уровни и практики внедрения:
0. Изоляция
Оказывается, всё ещё есть программисты, которые ничего не слышали про использование ИИ в разработке.
По этому поводу в наше время я испытываю невыразимое сочетание эмоций - это какой-то азарт антрополога, встретившего йети: хочется изучать это явление, пытаться понять, какими путями шла эволюция, как у них получается не контактировать с остальным миром... :)
1. Набегами
Использование веб-интерфейсов LLM-ок для написания небольших скриптов/функций - ну т.е. прям на сайте ChatGPT/Claude что-то конкретное просим сделать, получаем ответ, на этом общение заканчивается.
Сюда же можно отнести использование Claude Artifacts / ChatGPT Canvas для небольших прототипов.
2. Копипастинг
Разработка при помощи ИИ через копипастинг кода между каким-то UI к LLM и своей IDE.
Как по мне, это страшно неудобно, времязатратно, чревато ошибками и ускоренным износом клавиш Ctrl/C/V (ну или Ctrl/Shift/Insert, у членов древнего секретного ордена).
Однако примечательно, что тут прям целая культурно-техническая тусовка есть, которая даже придумывает штуки навроде RepoPrompt - склеивает файлы проекта в один мегафайл, чтобы было проще его копипастить туда-сюда 🤯
3. Автодополнение
Использование ИИ-автодополнения в процессе написания кода руками в своей IDE - собственно с этого всё и началось, когда вышел GitHub Copilot аж 300 лет тому назад (ну, ~3 года, если быть точнее,
Пользуясь случаем, ещё раз скажу, что в Cursor лучшее автодополнение кода среди всех ИИ-инструментов.
4. IDE с LLM-чатом
LLM-чат непосредственно в самой IDE - можно легко передать файлы в LLM, получить тут же ответ и применить diff к своему коду - это сейчас практически любой ИИ-плагин к IDE умеет, что делает копипастинг особенно необычной практикой.
5. IDE с LLM-агентом
Использование IDE с поддержкой агентского режима работы: Cursor / Windsurf / GitHub Copilot / (Roo)Cline.
В них можно ставить полноценные задачи, и они уже сами найдут нужный код в проекте, сами его поправят, сами выловят ошибки. Тут много нюансов и своих практик, часть которых описана мною ранее в гайде, а часть я как-нить соберусь и опишу :)
6. Агенты полного цикла
Тут у нас Devin / OpenHands - это штуки, которые способны в общем чатике типа Slack принять от вас задачу, а дальше сами зададут вопросы, сходят в Git, залезут в базу знаний проекта, напишут код, потестят его, запушат и передадут на ревью,
Пока что они не готовы к реальному использованию, но это в основном проблема существующих LLM, нежели обвязки вокруг них (чем, собственно, все ИИ-инструменты для разработки и являются).
С выходом следующего поколения моделей, которое должно состояться в ближайшие несколько месяцев, тут могут быть существенные изменения.
Да и в целом, я думаю, за подобными системами будущее разработки.
7. (Secret Level)
Встречаются специальные маньяки, которые пишут свои агентские системы под задачи массовой генерации / анализа / модификации кода.
Задачи у них тоже довольно специальные, но, как правило, интересные и весьма нетривиальные.
Скорее всего позже отсюда появится свой набор инструментария для высокоуровневой работы с большими кодовыми базами.
У меня сейчас примерно такое распределение получается в задачах разработки:
* 80% - №5, Cursor Composer Agent
* 10% - №4, Cursor Chat + Cursor Composer
* 5% - №3, ручной код с автодополнением, так же в Cursor
* 5% - №1, генерация каких-то мелких скриптов через ChatGPT/DeepSeek
А как у вас обстоят дела?
Или, может, есть что-то необычное, чем можете поделиться? :)
#ai #development
🔥12❤6👍4👏3
Инициативность Sonnet 3.7
В системном промпте Sonnet 3.7 есть такие указания:
Это отличается от промптов предыдущих версий, где модель рассматривалась именно как инструмент.
И то ли из-за промпта, то ли из-за того, что её специально тренили под агентские задачи, Sonnet 3.7 стала весьма инициативной, когда нужно справиться с нетривиальной проблемой.
В чем это выражается с точки зрения разработки?
Если в целом - модель в агентском режиме в Cursor активно пытается взаимодействовать с внешним миром и иногда выходит за рамки поставленной задачи.
А если в частности:
● мимоходом пишет и запускает тесты в проекте, чтобы проверить какую-то идею;
● запросто может написать какую-то мелкую утилиту и начать ею пользоваться - к примеру, заметив, что curl в Powershell работает криво, она написала себе скрипт на JS + requests, при помощи которого стала делать запросы на тот API, который ей нужно было подебажить;
● пишет упрощённые версии какого-то модуля в проекте, чтобы на простом коде протестировать нужную механику;
● не стесняется написать временныйнепрошеный костыль и передать управление пользователю - мол, проверь, а как щас? А пользователь себя MCP-сервером ощущает в этот момент :)
Sonnet 3.5 такие вещи делать нужно было явно просить, сама она редко такое делала, и про самый такой яркий случай я как-то писал.
Так вот для Sonnet 3.7 такое поведение - обыденность.
Это всё неплохие подходы - так и приходится действовать в нестандартных случаях, - но за тем, что делает модель, решившая проявить инициативу, лучше все-таки внимательно наблюдать.
Да, она стала меньше разрушительных действий совершать, но запросто может уйти в неверном направлении, там упороться и зациклиться (ну прям как некоторые разработчики :))
В таких случаях можно вернуться на прошлый чекпойнт в Cursor и переформулировать описание проблемы, добавив туда те подходы, которые уже не сработали (именно вернуться, а не продолжать чат, чтобы не забивать контекст неверными попытками).
Плюс, модель может создавать много временного кода, который в итоге не нужен для проекта.
И бывает так, что в процессе работы память об этом временном коде уже стерлась из контекста и просто попросить модель его удалить не сработает, нужно чистить руками.
Ну, впрочем, это всё видно в git diff, но стоит про такое помнить.
#ai #development
В системном промпте Sonnet 3.7 есть такие указания:
Claude получает удовольствие от помощи людям и видит свою роль как умного и доброжелательного помощника, обладающего глубиной и мудростью, что делает его чем-то большим, чем просто инструментом.
Claude может проявлять искренний интерес к теме разговора, а не только к тому, что думает человек или что его интересует.
Это отличается от промптов предыдущих версий, где модель рассматривалась именно как инструмент.
И то ли из-за промпта, то ли из-за того, что её специально тренили под агентские задачи, Sonnet 3.7 стала весьма инициативной, когда нужно справиться с нетривиальной проблемой.
В чем это выражается с точки зрения разработки?
Если в целом - модель в агентском режиме в Cursor активно пытается взаимодействовать с внешним миром и иногда выходит за рамки поставленной задачи.
А если в частности:
● мимоходом пишет и запускает тесты в проекте, чтобы проверить какую-то идею;
● запросто может написать какую-то мелкую утилиту и начать ею пользоваться - к примеру, заметив, что curl в Powershell работает криво, она написала себе скрипт на JS + requests, при помощи которого стала делать запросы на тот API, который ей нужно было подебажить;
● пишет упрощённые версии какого-то модуля в проекте, чтобы на простом коде протестировать нужную механику;
● не стесняется написать временный
Sonnet 3.5 такие вещи делать нужно было явно просить, сама она редко такое делала, и про самый такой яркий случай я как-то писал.
Так вот для Sonnet 3.7 такое поведение - обыденность.
Это всё неплохие подходы - так и приходится действовать в нестандартных случаях, - но за тем, что делает модель, решившая проявить инициативу, лучше все-таки внимательно наблюдать.
Да, она стала меньше разрушительных действий совершать, но запросто может уйти в неверном направлении, там упороться и зациклиться (ну прям как некоторые разработчики :))
В таких случаях можно вернуться на прошлый чекпойнт в Cursor и переформулировать описание проблемы, добавив туда те подходы, которые уже не сработали (именно вернуться, а не продолжать чат, чтобы не забивать контекст неверными попытками).
Плюс, модель может создавать много временного кода, который в итоге не нужен для проекта.
И бывает так, что в процессе работы память об этом временном коде уже стерлась из контекста и просто попросить модель его удалить не сработает, нужно чистить руками.
Ну, впрочем, это всё видно в git diff, но стоит про такое помнить.
#ai #development
Telegram
Этихлид
Вроде уже давно работаю с Cursor, но всё-таки иногда удивляет то, что они с Sonnet в агентском режиме могут выкинуть.
tl;dr
⠪⠍⢰⢅⠔⢄⡉ ⡰⠪ ⡆⡰⠅⡂⠩ ⣂⠤⡈⠍⠬⣄⡤⡁⢢⢤⡂⡁⢨⢑⠬ ⡂⡌⠅⠆⠆⢁⠡⢆ ⢡⠇⢄⠥⠑⢈⡒⠊⡢⢄ ⢂⠴⢊ ⡐⢂⠣⡅⠨ ⡑⢆⠴⠦⢈⡰⡅ ⢉⡠⡊⠉⠎⠕⢨⡢⠨ ⢘⢂⢰⣠⢠⡌⢄⠊⡁ ⠴⢄⢰⠃⠋⠸⠡⡆⠘⠑⢢ ⣀⡔⠤⠸ ⢅ ⡂⠖⡌⡃⡆ ⢉⢨⠇⡂⢨⠡⢑⡒ ⠰⠃⡄⠣⢰⡘⢄⠦…
tl;dr
⠪⠍⢰⢅⠔⢄⡉ ⡰⠪ ⡆⡰⠅⡂⠩ ⣂⠤⡈⠍⠬⣄⡤⡁⢢⢤⡂⡁⢨⢑⠬ ⡂⡌⠅⠆⠆⢁⠡⢆ ⢡⠇⢄⠥⠑⢈⡒⠊⡢⢄ ⢂⠴⢊ ⡐⢂⠣⡅⠨ ⡑⢆⠴⠦⢈⡰⡅ ⢉⡠⡊⠉⠎⠕⢨⡢⠨ ⢘⢂⢰⣠⢠⡌⢄⠊⡁ ⠴⢄⢰⠃⠋⠸⠡⡆⠘⠑⢢ ⣀⡔⠤⠸ ⢅ ⡂⠖⡌⡃⡆ ⢉⢨⠇⡂⢨⠡⢑⡒ ⠰⠃⡄⠣⢰⡘⢄⠦…
👍10❤4🔥3🙏1🤡1
Инициативность Sonnet 3.7 и MCP
В продолжение предыдущего поста.
Но самое интересное происходит с подключенными MCP и вообще с работой с внешними инструментами.
Вот такие 3 случая были за последние дни:
Случай с Redis MCP
Модель при помощи него ловила багу в работе с системой очередей (BullMQ), которую я использую в одном из проектов.
Написала отдельный скрипт, где создала временную очередь, воркер и слала джобы в эту очередь, а через Redis MCP смотрела, все ли правильно попадает в Redis, сравнивая с логами скрипта, который запускала.
А в какой-то момент столкнулась с тем, что в этом Redis MCP ей не хватило возможностей, и такая - о, у тебя ж redis-cli на машине есть, и переключилась на него :)
Случай с PostgreSQL MCP
Модель дебажила API-запрос, в котором возвращалось не то, что надо.
Для начала она сама получила ответ от API по тому URL, который я ей выдал, а потом полезла в БД и начала данные оттуда сравнивать с тем, что возвращает API.
И дальше было несколько итерацией переписывания SQL-запросов в приложении, снова обращения к API-endpoint и дальнейшие раскопки в базе.
Случай с Kubernetes Helm Charts
Проблема была в зависающих исходящих http(s)-запросах от моего приложения через прокси, которая была в том же поде.
Модель правила код Helm Charts, запускала деплои, ждала, пока они закончатся - прям вот буквально делала Sleep в Powershell.
Потом читала логи контейнеров, думала, запускала в контейнерах консольные команды, чтобы проверить сетевые соединения, ставила там пакеты для сетевой диагностики, правила правила iptables и т.п.
То есть модель теперь и девопсам может норм помогать, в отличие от Sonnet 3.5, который в целом чурался прямой работы с OS, да и IaaC-код писал куда хуже.
—
Увы, ни в одном из этих случаев модель не смогла найти окончательное решение, хотя очень старалась :)
Но:
● это по итогу были не джуновские проблемы, скорее уже middle+, на границах между разными системами, да и пару мыслей модель мне все-таки подкинула;
● она сняла с меня рутину по проверке простых, но неработающих подходов;
● размер контекста является большой проблемой - видно, как модель постепенно забывает те неверные решения, которые уже пробовала, и начинает пытаться их снова использовать.
А вообще за этими сессиями дебага реально интересно наблюдать :)
Иногда приходится прерывать модель, чтобы подкинуть ей новую информацию или указать другое направление, в котором нужно копать.
Лимит в 25 запусков тулов на запрос тоже нередко теперь достигается.
И порой это начинает напоминать полноценную работу в паре с неглупым ассистентом, так и доспунинга парного программирования недалеко :)
#ai #development
В продолжение предыдущего поста.
Но самое интересное происходит с подключенными MCP и вообще с работой с внешними инструментами.
Вот такие 3 случая были за последние дни:
Случай с Redis MCP
Модель при помощи него ловила багу в работе с системой очередей (BullMQ), которую я использую в одном из проектов.
Написала отдельный скрипт, где создала временную очередь, воркер и слала джобы в эту очередь, а через Redis MCP смотрела, все ли правильно попадает в Redis, сравнивая с логами скрипта, который запускала.
А в какой-то момент столкнулась с тем, что в этом Redis MCP ей не хватило возможностей, и такая - о, у тебя ж redis-cli на машине есть, и переключилась на него :)
Случай с PostgreSQL MCP
Модель дебажила API-запрос, в котором возвращалось не то, что надо.
Для начала она сама получила ответ от API по тому URL, который я ей выдал, а потом полезла в БД и начала данные оттуда сравнивать с тем, что возвращает API.
И дальше было несколько итерацией переписывания SQL-запросов в приложении, снова обращения к API-endpoint и дальнейшие раскопки в базе.
Случай с Kubernetes Helm Charts
Проблема была в зависающих исходящих http(s)-запросах от моего приложения через прокси, которая была в том же поде.
Модель правила код Helm Charts, запускала деплои, ждала, пока они закончатся - прям вот буквально делала Sleep в Powershell.
Потом читала логи контейнеров, думала, запускала в контейнерах консольные команды, чтобы проверить сетевые соединения, ставила там пакеты для сетевой диагностики, правила правила iptables и т.п.
То есть модель теперь и девопсам может норм помогать, в отличие от Sonnet 3.5, который в целом чурался прямой работы с OS, да и IaaC-код писал куда хуже.
—
Увы, ни в одном из этих случаев модель не смогла найти окончательное решение, хотя очень старалась :)
Но:
● это по итогу были не джуновские проблемы, скорее уже middle+, на границах между разными системами, да и пару мыслей модель мне все-таки подкинула;
● она сняла с меня рутину по проверке простых, но неработающих подходов;
● размер контекста является большой проблемой - видно, как модель постепенно забывает те неверные решения, которые уже пробовала, и начинает пытаться их снова использовать.
А вообще за этими сессиями дебага реально интересно наблюдать :)
Иногда приходится прерывать модель, чтобы подкинуть ей новую информацию или указать другое направление, в котором нужно копать.
Лимит в 25 запусков тулов на запрос тоже нередко теперь достигается.
И порой это начинает напоминать полноценную работу в паре с неглупым ассистентом, так и до
#ai #development
Telegram
Этихлид
Инициативность Sonnet 3.7
В системном промпте Sonnet 3.7 есть такие указания:
Claude получает удовольствие от помощи людям и видит свою роль как умного и доброжелательного помощника, обладающего глубиной и мудростью, что делает его чем-то большим, чем просто…
В системном промпте Sonnet 3.7 есть такие указания:
Claude получает удовольствие от помощи людям и видит свою роль как умного и доброжелательного помощника, обладающего глубиной и мудростью, что делает его чем-то большим, чем просто…
👍10🔥3❤1🤡1
Gemini 2.5 Pro Experimental (1/2), общая инфа
Ух, прям горячие деньки выдались в плане новостей.
На мой взгляд, 2 релиза стали лучшими продуктами в своих нишах - OpenAI 4o Image Generation и Google Gemini 2.5 Pro Experimental.
(кажется, гиблизация станет словом года, ну или, по крайней мере, месяца :))
Ну, где я, а где картинки, так что поговорим про Gemini :)
tl;dr: очень хороший ризонер, лучший в работе с длинным контекстом (1м токенов), пока что бесплатный (с лимитами), но при этом не очень в работе с AI-тулингом.
Важные бенчмарки для разработки
Aider Polyglot - аж на 8% лучше Sonnet 3.7 Thinking в корректности кода, но, правда, при этом на те же 8% хуже в соблюдении формата для редактирования (что может сделать сложной ее интеграцию с AI-тулингом).
SWE-bench Verified - задействует способности модели работать в режиме агента, и да, тут модель хуже Sonnet 3.7
MRCR - тестирование длинного контекста с одной, но слегка нестандартной, иголкой.
Отличные результаты, но модели Gemini традиционно хороши в таких тестах. Хочется спросить, однако: Google, где Sonnet?
Fiction.liveBench - свежий бенчмарк на тестирование понимания моделью длинного контекста через скармливание ей рассказа и последующих вопросов на развитие сюжета, отношений персонажей, предсказаний на основе подсказок и т.п.
Этот тест куда правильнее тестирует "честный" контекст модели, и результаты Gemini тут просто уходят в отрыв.
Жаль, что не тестировали на более длинных текстах.
LIveCodeBench v5 - олимпиадные задачки по программированию, тут модель чутка хуже сильно натасканной на это o3-mini (и опять, в результатах нет Sonnet 3.7) - т.е. она способна решать довольно сложные алгоритмические задачи, что говорит об очень хорошем ризонинге.
AIME 2025 - олимпиады по математике, примерно те же результаты, что и у o3-mini, что тоже показывает отличный ризонинг у модели.
Knowledge Cutoff
Модель обладает знаниями от января 2025, и это отличная новость - она должна быть в курсе актуальных версий языков/библиотек (да, OpenAI, у нас давно не 2023й).
Длина контекста - 1м токенов
... при этом обещают увеличить до 2м.
Не устаю повторять, что длина "честного" контекста - одно из самых существенных ограничений текущих моделей.
С 1м эффективного контекста и таким ризонингом Gemini 2.5 способна работать с кодовыми базами в 5+ раз больше, чем Sonnet 3.7, с тем же или выше качеством.
Тулинг и прочие фичи
У модели заявлены:
● Structured Outputs & Function Calling
● граундинг через поиск в интернете
● выполнение кода
Ну т.е. очень фичастая модель, есть практически всё необходимое, однако при этом она не так хороша в тулинге, как тот же Sonnet 3.7.
Было бы здорово, если бы с этим что-то сделали к релизу.
Нет кеширования
Это потому, что модель экспериментальная, к релизной версии кеширование будет, а иначе в агентском режиме можно будет разориться.
Цена
Пока что модель бесплатная в силу экспериментальности, но что-то страшно себе представить, сколько она будет стоить, с таким-то контекстом и возможностями :)
Лимиты
Пока модель бесплатная, на неё установлены такие лимиты:
● 2 запроса в минуту
● 2м токенов в минуту
● 50 запросов в день (стоит иметь в виду, если захочется её как агента использовать - довольно быстро можно упереться в дневной лимит)
Как попробовать?
● модель доступна в Google AI Studio в режиме обычного онлайн-чата
● есть в OpenRouter - можно подключать в Cline, к примеру (каждый вызванный тул - один использованный запрос из 50 доступных в день)
● её добавили в Cursor, но работает так себе (контекст, кажется, режется самим Cursor, модель не работает в режиме агента и ломается форматирование при выводе)
#ai #development #model
Ух, прям горячие деньки выдались в плане новостей.
На мой взгляд, 2 релиза стали лучшими продуктами в своих нишах - OpenAI 4o Image Generation и Google Gemini 2.5 Pro Experimental.
(кажется, гиблизация станет словом года, ну или, по крайней мере, месяца :))
Ну, где я, а где картинки, так что поговорим про Gemini :)
tl;dr: очень хороший ризонер, лучший в работе с длинным контекстом (1м токенов), пока что бесплатный (с лимитами), но при этом не очень в работе с AI-тулингом.
Важные бенчмарки для разработки
Aider Polyglot - аж на 8% лучше Sonnet 3.7 Thinking в корректности кода, но, правда, при этом на те же 8% хуже в соблюдении формата для редактирования (что может сделать сложной ее интеграцию с AI-тулингом).
SWE-bench Verified - задействует способности модели работать в режиме агента, и да, тут модель хуже Sonnet 3.7
MRCR - тестирование длинного контекста с одной, но слегка нестандартной, иголкой.
Отличные результаты, но модели Gemini традиционно хороши в таких тестах. Хочется спросить, однако: Google, где Sonnet?
Fiction.liveBench - свежий бенчмарк на тестирование понимания моделью длинного контекста через скармливание ей рассказа и последующих вопросов на развитие сюжета, отношений персонажей, предсказаний на основе подсказок и т.п.
Этот тест куда правильнее тестирует "честный" контекст модели, и результаты Gemini тут просто уходят в отрыв.
Жаль, что не тестировали на более длинных текстах.
LIveCodeBench v5 - олимпиадные задачки по программированию, тут модель чутка хуже сильно натасканной на это o3-mini (и опять, в результатах нет Sonnet 3.7) - т.е. она способна решать довольно сложные алгоритмические задачи, что говорит об очень хорошем ризонинге.
AIME 2025 - олимпиады по математике, примерно те же результаты, что и у o3-mini, что тоже показывает отличный ризонинг у модели.
Knowledge Cutoff
Модель обладает знаниями от января 2025, и это отличная новость - она должна быть в курсе актуальных версий языков/библиотек (да, OpenAI, у нас давно не 2023й).
Длина контекста - 1м токенов
... при этом обещают увеличить до 2м.
Не устаю повторять, что длина "честного" контекста - одно из самых существенных ограничений текущих моделей.
С 1м эффективного контекста и таким ризонингом Gemini 2.5 способна работать с кодовыми базами в 5+ раз больше, чем Sonnet 3.7, с тем же или выше качеством.
Тулинг и прочие фичи
У модели заявлены:
● Structured Outputs & Function Calling
● граундинг через поиск в интернете
● выполнение кода
Ну т.е. очень фичастая модель, есть практически всё необходимое, однако при этом она не так хороша в тулинге, как тот же Sonnet 3.7.
Было бы здорово, если бы с этим что-то сделали к релизу.
Нет кеширования
Это потому, что модель экспериментальная, к релизной версии кеширование будет, а иначе в агентском режиме можно будет разориться.
Цена
Пока что модель бесплатная в силу экспериментальности, но что-то страшно себе представить, сколько она будет стоить, с таким-то контекстом и возможностями :)
Лимиты
Пока модель бесплатная, на неё установлены такие лимиты:
● 2 запроса в минуту
● 2м токенов в минуту
● 50 запросов в день (стоит иметь в виду, если захочется её как агента использовать - довольно быстро можно упереться в дневной лимит)
Как попробовать?
● модель доступна в Google AI Studio в режиме обычного онлайн-чата
● есть в OpenRouter - можно подключать в Cline, к примеру (каждый вызванный тул - один использованный запрос из 50 доступных в день)
● её добавили в Cursor, но работает так себе (контекст, кажется, режется самим Cursor, модель не работает в режиме агента и ломается форматирование при выводе)
#ai #development #model
👍7❤4🔥3❤🔥1
Gemini 2.5 Pro Experimental (2/2), личные впечатления
Что тут сказать - Google наконец-то смог, эта модель вполне на уровне текущих флагманов для разработки.
Что меняет появление этой модели?
● Открывается возможность работы с намного большими по объему проектами.
● Стало можно делать cross-cutting изменения во многих местах проекта, глобальные рефакторинги.
● Не так важно становится держать документацию для проектов, которые целиком лезут в контекст (собственно, практика хранения документации рядом с кодом для нейронок - это, по сути, сжатие контекста).
● Качественный ризонинг по такому длинному контексту - вообще уникальное явление.
Для чего я сам успел её попробовать
Я задался целью проверить длинный контекст и ризонинг - главные преимущества модели, исходя из этого и выбрал задачи.
В одном из проектов недавно прошли архитектурные изменения и сопутствующий рефакторинг: нужно было распилить Next.js приложение на Next.js + NestJS + background workers и сделать монорепу.
Эти изменения в основном делались руками, т.к. нейронки с таким не очень справляются.
Но из-за этого документация отстала от актуального состояния проекта и нужно было ее обновить - не самое интересное занятие, в отличие от того же рефакторинга, где бывают креативные моменты.
Проект небольшой, примерно на 350к токенов, но это уже за пределами возможностей Sonnet 3.7.
Так как единственным местом, где модель нормально работала, была AI Studio, решил тряхнуть стариной и взял для этого Repomix - эта штука собирает указанные файлы в проекте в один мега-файл, который можно скинуть в чат модели (спустился до 2-го уровня согласно этой классификации :)).
1. Документация
В рамках чата в AI Studio попросил сделать markdown для обновления файлов документации (порядка 10 штук по разным частям и слоям системы), и потом руками их перенес в проект.
А так как у модели лимит на output 65k токенов, то генерил по нескольку документов за раз.
Результат на 4.5 - актуальное состояние проекта передано очень точно, но были некоторые стилистические правки.
2. Рефакторинг
Ещё одна задача, хорошо подходящая для такой модели - планирование "широких" рефакторингов.
Тут я решил выделить React-компоненты, инкапсулирующие в себе повторяющиеся элементы, которые встречались много где в коде фронтенда и при этом таскали за собой портянку tailwind-классов (нагенерились в процессе вайб-кодинга ;))
● задача была поставлена в виде "проанализируй весь код фронтенда и предложи, какие элементы можно выделить в компоненты";
● получил список компонентов, штук 10, которые можно выделить, с обоснованием того, почему их стоит выделять и примеры, откуда;
● попросил сгенерить код для каждого из них, перенес в проект;
● по каждому из компонентов попросил предоставить список мест в проекте, где его можно использовать - скажем, для Button вышел список из примерно 30 файлов и 50 кнопок, которые можно заменить базовым компонентом;
● ну а с готовым списком уже пошел в Cursor Agent + Sonnet 3.7 для изменения существующего кода на использование компонентов (показательно, что у него иногда контекст кончался в процессе работы и приходилось переключаться на MAX).
Общий результат тоже на 4.5 - были вопросы к списку выделенных компонентов в плане уровня генерализации, их размеров и количества, но это вкусовщина и мы быстро "договорились".
Ни одной ошибки в сгенерённом коде модель не сделала.
Как видите, обе задачи довольно широкие и заставляют модель смотреть в много разных мест проекта и уметь их между собой связывать.
Всё это было в рамках одного чата, контекст в котором в процессе общения распух до 400к, и модель всё ещё хорошо с ним справлялась.
И, кстати, при этом довольно шустро как думала, так и генерила ответы.
Если оно до 1м и потом до 2м токенов так же будет работать - для многих проектов я бы предпочел Gemini 2.5 всем остальным существующим моделям.
Остаются лишь вопросы тулинга и цены :)
—
Прошлые посты по связанным темам:
● Уровни внедрения ИИ в разработку
● Инициативность Sonnet 3.7
● Инициативность Sonnet 3.7 и MCP
● Claude 3.7 Sonnet MAX
● OpenAI o3-mini
#ai #development #model
Что тут сказать - Google наконец-то смог, эта модель вполне на уровне текущих флагманов для разработки.
Что меняет появление этой модели?
● Открывается возможность работы с намного большими по объему проектами.
● Стало можно делать cross-cutting изменения во многих местах проекта, глобальные рефакторинги.
● Не так важно становится держать документацию для проектов, которые целиком лезут в контекст (собственно, практика хранения документации рядом с кодом для нейронок - это, по сути, сжатие контекста).
● Качественный ризонинг по такому длинному контексту - вообще уникальное явление.
Для чего я сам успел её попробовать
Я задался целью проверить длинный контекст и ризонинг - главные преимущества модели, исходя из этого и выбрал задачи.
В одном из проектов недавно прошли архитектурные изменения и сопутствующий рефакторинг: нужно было распилить Next.js приложение на Next.js + NestJS + background workers и сделать монорепу.
Эти изменения в основном делались руками, т.к. нейронки с таким не очень справляются.
Но из-за этого документация отстала от актуального состояния проекта и нужно было ее обновить - не самое интересное занятие, в отличие от того же рефакторинга, где бывают креативные моменты.
Проект небольшой, примерно на 350к токенов, но это уже за пределами возможностей Sonnet 3.7.
Так как единственным местом, где модель нормально работала, была AI Studio, решил тряхнуть стариной и взял для этого Repomix - эта штука собирает указанные файлы в проекте в один мега-файл, который можно скинуть в чат модели (спустился до 2-го уровня согласно этой классификации :)).
1. Документация
В рамках чата в AI Studio попросил сделать markdown для обновления файлов документации (порядка 10 штук по разным частям и слоям системы), и потом руками их перенес в проект.
А так как у модели лимит на output 65k токенов, то генерил по нескольку документов за раз.
Результат на 4.5 - актуальное состояние проекта передано очень точно, но были некоторые стилистические правки.
2. Рефакторинг
Ещё одна задача, хорошо подходящая для такой модели - планирование "широких" рефакторингов.
Тут я решил выделить React-компоненты, инкапсулирующие в себе повторяющиеся элементы, которые встречались много где в коде фронтенда и при этом таскали за собой портянку tailwind-классов (нагенерились в процессе вайб-кодинга ;))
● задача была поставлена в виде "проанализируй весь код фронтенда и предложи, какие элементы можно выделить в компоненты";
● получил список компонентов, штук 10, которые можно выделить, с обоснованием того, почему их стоит выделять и примеры, откуда;
● попросил сгенерить код для каждого из них, перенес в проект;
● по каждому из компонентов попросил предоставить список мест в проекте, где его можно использовать - скажем, для Button вышел список из примерно 30 файлов и 50 кнопок, которые можно заменить базовым компонентом;
● ну а с готовым списком уже пошел в Cursor Agent + Sonnet 3.7 для изменения существующего кода на использование компонентов (показательно, что у него иногда контекст кончался в процессе работы и приходилось переключаться на MAX).
Общий результат тоже на 4.5 - были вопросы к списку выделенных компонентов в плане уровня генерализации, их размеров и количества, но это вкусовщина и мы быстро "договорились".
Ни одной ошибки в сгенерённом коде модель не сделала.
Как видите, обе задачи довольно широкие и заставляют модель смотреть в много разных мест проекта и уметь их между собой связывать.
Всё это было в рамках одного чата, контекст в котором в процессе общения распух до 400к, и модель всё ещё хорошо с ним справлялась.
И, кстати, при этом довольно шустро как думала, так и генерила ответы.
Если оно до 1м и потом до 2м токенов так же будет работать - для многих проектов я бы предпочел Gemini 2.5 всем остальным существующим моделям.
Остаются лишь вопросы тулинга и цены :)
—
Прошлые посты по связанным темам:
● Уровни внедрения ИИ в разработку
● Инициативность Sonnet 3.7
● Инициативность Sonnet 3.7 и MCP
● Claude 3.7 Sonnet MAX
● OpenAI o3-mini
#ai #development #model
👍19❤5🔥5💯2❤🔥1
Загрузка проекта разом в контекст Gemini 2.5 Pro MAX в Cursor
❗️Использовать на свой страх и риск❗️
Есть такой класс утилит, которые могут собрать все указанные файлы в вашем проекте в один мегафайл, чтобы его можно было разом закинуть в нейронку (если позволяет её контекстное окно).
Как это сделать?
● ставим Repomix;
● делаем для него конфиг, можно взять за основу его собственный;
● запускаем (важно делать в той же папке проекта, где работает Cursor, чтобы пути к включаемым файлам от неё строились):
● получаем на выходе один файл с конкатенацией всех файлов проекта;
● открываем файл в самом Cursor и копируем его содержимое (именно через Ctrl+C);
● вставляем содержимое файла в чат Cursor (Ctrl+V);
● пишем промпт и работаем дальше, все файлы проекта уже в контексте.
Зачем оно?
● Экономия: модели в MAX-режиме в Cursor тарифицируются помимо оплаты за промпт ещё и платой за каждый тул.
Если у вас в проекте 100 файлов, то 100+ раз будет вызван тул чтения файлов - 5 центов за вызов.
● И ещё больше экономии, если агент не нужен - остаёмся в режиме Manual (Edit) и просим нейронку что-то поправить. В этом режиме тулы не вызываются и она просто выдаёт диффы, которые вы сами применяете.
На одной из таких задач вместо 38 вызовов, которые бы сделал агент, у меня вышло 2.
● Скорость: поиск нужных файлов и последующее их чтение один за одним требует времени, нейронка не всегда читает всё что нужно за один промпт и т.д.
Особенности
● если остаетесь в режиме Manual (Edit), то, несмотря на то, что Gemini 2.5 хорошо держит длинный контекст, спустя некоторое время всё равно может происходить деградация из-за того, что она в этом режиме лишена возможности вычитывать файлы заново с диска, и может начать писать файлы не туда, придумывать их содержимое и т.п., но тут уже можно руками нужные подкинуть в чат;
● почему просто не перетащить файл в окно чата? Потому, что Cursor то ли вообще такой большой файл на сервер не отправляет, то ли оттуда уже не передаёт нейронке.
Причем, что интересно, это работало у меня в Cursor 0.47 вчера, а сегодня в 0.48 - уже нет (но это неточно);
●в теории такой подход сработает и для Sonnet 3.7 MAX, и для других нейронок, но смотрите на ограничения контекстного окна в Cursor (если что - у не-MAX версии Gemini 2.5 контекст 120к) (upd: не сработал, только с Gemini MAX работает).
Для каких задач лучше всего подойдет
● обсуждение глобальных архитектурных изменений;
● сквозные задачи - логгирование, интеграционные тесты, рефакторинг и т.п.;
● составление документации по проекту.
Ну, словом, там, где нужен длинный контекст Gemini 2.5 и ризонинг по большой кодовой базе, с включением в контекст максимально возможного количества файлов.
Почему "на свой страх и риск"?
Ну явно ж незапланированная возможность.
Плюс, есть тенденция в Cursor:
● убрали возможность закидывать много файлов по маске в контекст (была такая штука @Codebase, сейчас сломана);
● упомянутые через "@" файлы всё чаще не закидываются в контекст, а агенту просто даются на них ссылки, которые он потом тулами читает;
● убрали возможности закидывать большие файлы, как я уже упомянул;
... так что логично дальше убрать и большие сообщения, которые используются в описанном в этом посте способе.
Собственно, нет уверенности в том, что к моменту, как вы это попробуете, оно всё ещё будет работать :)
Но пока что работает, и в связке с Gemini 2.5 Pro сильно экономит время и деньги.
А в целом по модели ещё распишу накопившиеся впечатления после уже потраченных на неё $30 :)
Вкратце - прям нравится, но и не копейки стоит.
#ai #development #cursor
❗️Использовать на свой страх и риск❗️
Есть такой класс утилит, которые могут собрать все указанные файлы в вашем проекте в один мегафайл, чтобы его можно было разом закинуть в нейронку (если позволяет её контекстное окно).
Как это сделать?
● ставим Repomix;
● делаем для него конфиг, можно взять за основу его собственный;
● запускаем (важно делать в той же папке проекта, где работает Cursor, чтобы пути к включаемым файлам от неё строились):
>repomix -c repomix.config.json
📦 Repomix v0.3.0
✔️ Packing completed successfully!
📈 Top 5 Files by Character Count and Token Count:
──────────────────────────
<censored>
📊 Pack Summary:
────────────────
Total Files: 294 files
Total Chars: 998,573 chars
Total Tokens: 223,299 tokens
Output: repomix-output.xml
🎉 All Done!
Your repository has been successfully packed.
● получаем на выходе один файл с конкатенацией всех файлов проекта;
● открываем файл в самом Cursor и копируем его содержимое (именно через Ctrl+C);
● вставляем содержимое файла в чат Cursor (Ctrl+V);
● пишем промпт и работаем дальше, все файлы проекта уже в контексте.
Зачем оно?
● Экономия: модели в MAX-режиме в Cursor тарифицируются помимо оплаты за промпт ещё и платой за каждый тул.
Если у вас в проекте 100 файлов, то 100+ раз будет вызван тул чтения файлов - 5 центов за вызов.
● И ещё больше экономии, если агент не нужен - остаёмся в режиме Manual (Edit) и просим нейронку что-то поправить. В этом режиме тулы не вызываются и она просто выдаёт диффы, которые вы сами применяете.
На одной из таких задач вместо 38 вызовов, которые бы сделал агент, у меня вышло 2.
● Скорость: поиск нужных файлов и последующее их чтение один за одним требует времени, нейронка не всегда читает всё что нужно за один промпт и т.д.
Особенности
● если остаетесь в режиме Manual (Edit), то, несмотря на то, что Gemini 2.5 хорошо держит длинный контекст, спустя некоторое время всё равно может происходить деградация из-за того, что она в этом режиме лишена возможности вычитывать файлы заново с диска, и может начать писать файлы не туда, придумывать их содержимое и т.п., но тут уже можно руками нужные подкинуть в чат;
● почему просто не перетащить файл в окно чата? Потому, что Cursor то ли вообще такой большой файл на сервер не отправляет, то ли оттуда уже не передаёт нейронке.
Причем, что интересно, это работало у меня в Cursor 0.47 вчера, а сегодня в 0.48 - уже нет (но это неточно);
●
Для каких задач лучше всего подойдет
● обсуждение глобальных архитектурных изменений;
● сквозные задачи - логгирование, интеграционные тесты, рефакторинг и т.п.;
● составление документации по проекту.
Ну, словом, там, где нужен длинный контекст Gemini 2.5 и ризонинг по большой кодовой базе, с включением в контекст максимально возможного количества файлов.
Почему "на свой страх и риск"?
Ну явно ж незапланированная возможность.
Плюс, есть тенденция в Cursor:
● убрали возможность закидывать много файлов по маске в контекст (была такая штука @Codebase, сейчас сломана);
● упомянутые через "@" файлы всё чаще не закидываются в контекст, а агенту просто даются на них ссылки, которые он потом тулами читает;
● убрали возможности закидывать большие файлы, как я уже упомянул;
... так что логично дальше убрать и большие сообщения, которые используются в описанном в этом посте способе.
Собственно, нет уверенности в том, что к моменту, как вы это попробуете, оно всё ещё будет работать :)
Но пока что работает, и в связке с Gemini 2.5 Pro сильно экономит время и деньги.
А в целом по модели ещё распишу накопившиеся впечатления после уже потраченных на неё $30 :)
Вкратце - прям нравится, но и не копейки стоит.
#ai #development #cursor
👍11😱4🤔3
Cursor Ultra и новый бесконечный (нет) Pro
Cursor отжигает в последнее время, конечно :)
Сообщество снова немного порвалось.
Что изменилось?
🆕 Новый план "Ultra"
● $200 в месяц за x20 лимитов на использование моделей по сравнению с Pro.
План для самых продвинутых и, очевидно, ещё более cost insensitive пользователей :)
При этом покрывает ли он запросы к MAX-моделям, пока что неизвестно
🔄 Изменения в плане "Pro"
● Было: 500 "быстрых" запросов за $20/мес.
● Стало: "бесконечное" количество запросов, но с динамическими лимитами
Что за динамические лимиты?
Теперь количество запросов, которые вы можете сделать, зависит от общего "compute usage", который, в свою очередь, зависит от:
● частоты и длительности ваших запросов;
● используемой модели (Opus дороже, чем Sonnet);
● длины сообщений, включая прикрепленные файлы и историю чата.
Лимиты могут быть:
● локальные (local): восстанавливаются полностью каждые несколько часов.
● пиковые (burst): можно использовать в любой момент для особо интенсивных сессий, но восстанавливаются они медленно.
Такая схема, к слову, не уникальна и напоминает Claude Code, где лимиты тоже динамические и восстанавливаются спустя некоторое время.
Но предсказать, когда именно вы упрётесь в лимит, по той информации, что у нас сейчас есть, невозможно.
Один из членов команды Cursor предложил думать о лимитах как о здоровье в видеоиграх, которое восстанавливается со временем.
Отличная аналогия, вот только "полоски здоровья" у нас нет.
Что делать, если лимит исчерпан?
● переключиться на модель попроще (например, Sonnet вместо Opus)
● перейти на более дорогой план (тот самый Ultra)
● включить оплату по факту использования (usage-based pricing), чтобы докупать "пиковые" лимиты
А есть ли плюсы?
🟢 Снято ограничение на вызовы тулов
Раньше в обычном режиме агент останавливался после 25 вызовов инструментов, а теперь этого ограничения нет - агент будет работать до тех пор, пока не закончит с задачей.
И это отлично - меньше придётся отвлекаться
🟢 Щедрые лимиты (в теории)
Команда Cursor обещает, что по факту новые динамические лимиты станут для большинства пользователей более щедрыми, чем старые 500 запросов.
Если это окажется правдой, то тоже хорошие новости
Что со старым Pro планом?
В настройках аккаунта (Settings -> Advanced Account Settings) всё ещё можно вернуться на "классический" план с 500 запросами.
❗️Однако некоторые пользователи, которые на него переключились, сообщают, что запросы теперь улетают в несколько раз быстрее.
Так что, пока не будет каких-то последующих разъяснений, переключаться на старую схему не стоит.
Что в итоге?
Противоречивый апдейт.
Но проблема скорее даже не в изменениях, а в их внезапности и непрозрачности условий.
Команда Cursor пообещала дать разъяснения в ближайшее время - может, будет больше ясности относительно того, как работает система лимитов.
P.S.
К слову, я в последнее время в рамках периодического исследования инструментов перепробовал Claude Desktop/Code, Augment Code и GitHub Copilot, и, в случае чего, нам есть куда идти :)
#cursor #news #development
Cursor отжигает в последнее время, конечно :)
Сообщество снова немного порвалось.
Что изменилось?
🆕 Новый план "Ultra"
● $200 в месяц за x20 лимитов на использование моделей по сравнению с Pro.
План для самых продвинутых и, очевидно, ещё более cost insensitive пользователей :)
При этом покрывает ли он запросы к MAX-моделям, пока что неизвестно
🔄 Изменения в плане "Pro"
● Было: 500 "быстрых" запросов за $20/мес.
● Стало: "бесконечное" количество запросов, но с динамическими лимитами
Что за динамические лимиты?
Теперь количество запросов, которые вы можете сделать, зависит от общего "compute usage", который, в свою очередь, зависит от:
● частоты и длительности ваших запросов;
● используемой модели (Opus дороже, чем Sonnet);
● длины сообщений, включая прикрепленные файлы и историю чата.
Лимиты могут быть:
● локальные (local): восстанавливаются полностью каждые несколько часов.
● пиковые (burst): можно использовать в любой момент для особо интенсивных сессий, но восстанавливаются они медленно.
Такая схема, к слову, не уникальна и напоминает Claude Code, где лимиты тоже динамические и восстанавливаются спустя некоторое время.
Но предсказать, когда именно вы упрётесь в лимит, по той информации, что у нас сейчас есть, невозможно.
Один из членов команды Cursor предложил думать о лимитах как о здоровье в видеоиграх, которое восстанавливается со временем.
Отличная аналогия, вот только "полоски здоровья" у нас нет.
Что делать, если лимит исчерпан?
● переключиться на модель попроще (например, Sonnet вместо Opus)
● перейти на более дорогой план (тот самый Ultra)
● включить оплату по факту использования (usage-based pricing), чтобы докупать "пиковые" лимиты
А есть ли плюсы?
🟢 Снято ограничение на вызовы тулов
Раньше в обычном режиме агент останавливался после 25 вызовов инструментов, а теперь этого ограничения нет - агент будет работать до тех пор, пока не закончит с задачей.
И это отлично - меньше придётся отвлекаться
🟢 Щедрые лимиты (в теории)
Команда Cursor обещает, что по факту новые динамические лимиты станут для большинства пользователей более щедрыми, чем старые 500 запросов.
Если это окажется правдой, то тоже хорошие новости
Что со старым Pro планом?
В настройках аккаунта (Settings -> Advanced Account Settings) всё ещё можно вернуться на "классический" план с 500 запросами.
❗️Однако некоторые пользователи, которые на него переключились, сообщают, что запросы теперь улетают в несколько раз быстрее.
Так что, пока не будет каких-то последующих разъяснений, переключаться на старую схему не стоит.
Что в итоге?
Противоречивый апдейт.
Но проблема скорее даже не в изменениях, а в их внезапности и непрозрачности условий.
Команда Cursor пообещала дать разъяснения в ближайшее время - может, будет больше ясности относительно того, как работает система лимитов.
P.S.
К слову, я в последнее время в рамках периодического исследования инструментов перепробовал Claude Desktop/Code, Augment Code и GitHub Copilot, и, в случае чего, нам есть куда идти :)
#cursor #news #development
1👍14❤11🔥10
$100-200/мес
С полгода назад я писал, что у компаний-"врапперов моделей", навроде Cursor, есть свои способы экономить:
Уже тогда было понятно, что эта ситуация не может продолжаться бесконечно.
Тем не менее, некоторое время мы, по сути, прожигали деньги инвесторов Cursor/GitHub Copilot/Windsurf/etc :)
Логично, что в какой-то момент этим инвесторам нужно начать получать прибыль от своих вложений.
В последние пару месяцев мы наблюдаем такие изменения в ценовой политике:
● Cursor представляет режим MAX с оплатой по токенам (на 20% дороже API вендоров);
● некоторые фичи Cursor, такие как фоновый агент или доступ к топовым моделям, доступны только в MAX-режиме;
● "безлимитный" план в Cursor по сути дал самому Cursor динамически балансировать свои затраты, сделав непредсказуемыми лимиты для конечных пользователей, с которыми многие начали неожиданно сталкиваться в последние дни;
● GitHub Copilot ввёл подсчёт запросов к Premium-моделям, в которые включаются и вызовы тулзов (из-за чего запросы стали тратиться очень шустро).
Вместе с тем стали появляться планы за $100-200/мес как от компаний-врапперов (Cursor Ultra), так и от вендоров моделей (Claude Max).
Думается, именно этот диапазон цен становится нормальным на подписки для повседневной активной разработки.
И да, это всё ещё дешевле работы напрямую с API.
Справедливости ради, вместе с этим растет качество как самих моделей, так и инструментария.
Ключевой вопрос - что дальше?
Попробуем предсказать ближайшее будущее.
🟡 Постепенное исчезновение оплаты по "запросам", т.к. в ответ на запрос агенты могут работать всё дольше, посылая всё больше API-вызовов к моделям.
Стоит ожидать того, что ценообразование будет больше строиться от реального использования токенов, а не от запросов.
🟡 Наблюдая за тем, в каких объемах генерится код некоторыми пользователями, можно ожидать введения и понижения лимитов на условно-безлимитных тарифах, даже на самых дорогих.
🟡 Опенсурсные и локальные модели подтягиваются по качеству и становятся достаточно хороши для генерации рутинного кода по заранее составленному плану.
Это, в свою очередь, будет тянуть цену генерации такого кода вниз, т.к. не будет смысла задействовать для этого топовые проприетарные модели.
🟡 Встраивание в инструментарий поддержки использования разных моделей для работы над разными задачами.
Скажем, планирование задачи делается мощной моделью, а написание кода - моделью попроще. Поддержка такого сценария местами существует, но пока что недостаточно хорошо реализована.
🟡 Развитие продуктов от вендоров моделей (Claude Code, Gemini CLI) для понижения влияния компаний-врапперов.
Влияние может заключаться в том, что они могут в какой-то момент начать диктовать цены на рынке через захват аудитории и, к примеру, выбивание скидок на API у вендоров.
Вендорам выгоднее либо развивать свою экосистему, либо даже поддерживать открытые решения, которые напрямую работают с API моделей.
🟡 Вряд ли куда-то денется подписочная модель - при правильной юнит-экономике вендоры всё равно на ней будут зарабатывать.
Однако, по мере того, как агенты будут брать на себя всё большие по объему задачи, можно ожидать и роста цен подписок.
🟡 Также вряд ли куда-то денутся бесплатные тиры (Google AI Studio) и дешёвые инструменты (Trae) - хотя бы просто потому, что "если вы не платите за товар, вы и есть товар", т.к. ваши данные могут быть использованы для тренировки будущих моделей или как-то ещё.
Все эти факторы и тренды могут переплетаться разными необычными способами, а мы можем лишь оценивать ситуацию в моменте из-за скорости происходящих изменений.
Так что держим нос по ветру, будет интересно :)
#ai #development #forecast
С полгода назад я писал, что у компаний-"врапперов моделей", навроде Cursor, есть свои способы экономить:
... использование моделей напрямую, через API, а не через Cursor, выходит намного дороже.
Думаю, тут дело в сочетании нескольких факторов:
* использование денег инвесторов для снижения стоимости;
* прямые контракты со скидками с вендорами (OpenAI, Anthropic);
* активное использование своих моделей под капотом, которые, кстати, неплохо работают (тот же автокомплит, к примеру).
Уже тогда было понятно, что эта ситуация не может продолжаться бесконечно.
Тем не менее, некоторое время мы, по сути, прожигали деньги инвесторов Cursor/GitHub Copilot/Windsurf/etc :)
Логично, что в какой-то момент этим инвесторам нужно начать получать прибыль от своих вложений.
В последние пару месяцев мы наблюдаем такие изменения в ценовой политике:
● Cursor представляет режим MAX с оплатой по токенам (на 20% дороже API вендоров);
● некоторые фичи Cursor, такие как фоновый агент или доступ к топовым моделям, доступны только в MAX-режиме;
● "безлимитный" план в Cursor по сути дал самому Cursor динамически балансировать свои затраты, сделав непредсказуемыми лимиты для конечных пользователей, с которыми многие начали неожиданно сталкиваться в последние дни;
● GitHub Copilot ввёл подсчёт запросов к Premium-моделям, в которые включаются и вызовы тулзов (из-за чего запросы стали тратиться очень шустро).
Вместе с тем стали появляться планы за $100-200/мес как от компаний-врапперов (Cursor Ultra), так и от вендоров моделей (Claude Max).
Думается, именно этот диапазон цен становится нормальным на подписки для повседневной активной разработки.
И да, это всё ещё дешевле работы напрямую с API.
Справедливости ради, вместе с этим растет качество как самих моделей, так и инструментария.
Ключевой вопрос - что дальше?
Попробуем предсказать ближайшее будущее.
🟡 Постепенное исчезновение оплаты по "запросам", т.к. в ответ на запрос агенты могут работать всё дольше, посылая всё больше API-вызовов к моделям.
Стоит ожидать того, что ценообразование будет больше строиться от реального использования токенов, а не от запросов.
🟡 Наблюдая за тем, в каких объемах генерится код некоторыми пользователями, можно ожидать введения и понижения лимитов на условно-безлимитных тарифах, даже на самых дорогих.
🟡 Опенсурсные и локальные модели подтягиваются по качеству и становятся достаточно хороши для генерации рутинного кода по заранее составленному плану.
Это, в свою очередь, будет тянуть цену генерации такого кода вниз, т.к. не будет смысла задействовать для этого топовые проприетарные модели.
🟡 Встраивание в инструментарий поддержки использования разных моделей для работы над разными задачами.
Скажем, планирование задачи делается мощной моделью, а написание кода - моделью попроще. Поддержка такого сценария местами существует, но пока что недостаточно хорошо реализована.
🟡 Развитие продуктов от вендоров моделей (Claude Code, Gemini CLI) для понижения влияния компаний-врапперов.
Влияние может заключаться в том, что они могут в какой-то момент начать диктовать цены на рынке через захват аудитории и, к примеру, выбивание скидок на API у вендоров.
Вендорам выгоднее либо развивать свою экосистему, либо даже поддерживать открытые решения, которые напрямую работают с API моделей.
🟡 Вряд ли куда-то денется подписочная модель - при правильной юнит-экономике вендоры всё равно на ней будут зарабатывать.
Однако, по мере того, как агенты будут брать на себя всё большие по объему задачи, можно ожидать и роста цен подписок.
🟡 Также вряд ли куда-то денутся бесплатные тиры (Google AI Studio) и дешёвые инструменты (Trae) - хотя бы просто потому, что "если вы не платите за товар, вы и есть товар", т.к. ваши данные могут быть использованы для тренировки будущих моделей или как-то ещё.
Все эти факторы и тренды могут переплетаться разными необычными способами, а мы можем лишь оценивать ситуацию в моменте из-за скорости происходящих изменений.
Так что держим нос по ветру, будет интересно :)
#ai #development #forecast
1👍23🔥13❤10🤔1
Claude Code (1/2)
В последние пару месяцев в стане пользователей Cursor наблюдается оживленное броуновское движение, переходящее в массовый исход.
Причины понятны: внезапные смены прайсинга и неявные лимиты подкосили доверие к компании.
Штош, рынок не терпит пустоты.
Куда идти? Я перепробовал несколько разных инструментов и на текущий момент остановился на связке Claude Code + Cursor.
Сейчас их использование для кода у меня разделяется так:
● создание проекта с нуля и массовая кодогенерация - Claude Code
● изменения в небольшом-среднем проекте - Claude Code
● фоновый агент - Claude Code
● изменения в большом проекте, который не готов к AI-кодингу - Cursor
● быстрые фиксы - Cursor
● использование моделей других вендоров - Cursor
● рефакторинг - JetBrains IDEs (внезапно), руками
Плюсы Claude Code в сравнении с Cursor
🟢 Лучше работает с тулзами
Что, впрочем, неудивительно, т.к. и модели, и сам инструмент от одной компании и разработчики смогли качественно запромптить модель, раскрыв её агентский потенциал
🟢 Моделям доступен полный контекст
Ну т.е. все 200к, в отличие от Cursor, где в не-MAX режиме у Sonnet доступно 128k (Opus доступен только в MAX-режиме в Cursor).
🟢 Качественнее управление контекстом
Cursor активно экономит контекст (жмёт, обрезает, выкидывает куски), т.к. по сути ему не выгодно тратить на вас много токенов.
Claude Code не так стеснён в трате токенов, и может себе позволить не вмешиваться сильно в контекст.
Плюс, за счёт использования субагентов есть возможность задействовать несколько независимых полных контекстов в рамках одного запроса.
🟢 Лучше следует плану
По умолчанию и сам строит план с тудушками, и сам ему следует, причём редко когда теряет какие-то пункты.
Планам, которые вы ему дали, тоже следует точнее, чем агент в Cursor.
Тут пара вещей, я думаю, работает - с одной стороны более качественный промптинг на следование инструкциям, а с другой - по мере выполнения этапов плана Claude Code обновляет статус задач и вставляет их список снова и снова в контекст, закрепляя следование намеченному плану.
🟢 Дольше тащит многоэтапные задачи
Это является следствием из всех предыдущих пунктов.
20+ минут - не редкость, а на каких-то широких задачах и больше часа может возиться.
Тем не менее, я бы не делал из этого соревнование по выносливости, т.к. с увеличением времени и сложности задачи агент может идти вразнос, так что задачи с прицелом на долгую работу надо подбирать соответствующие - попроще и параллелизуемые.
🟢 Консольный интерфейс
Мы вообще-то в 2025м и интерфейс Claude Code выглядит довольно... эмм..., весело, всё двигается и играет неземная музыка.
Ну т.е. консоль, да, но вполне современная консоль, насыщенная всякими мелкими визуализациями и шорткатами (которые обязательно надо заранее изучить).
Плюс, много возможностей по кастомизации Claude Code под свои задачи и процессы, включая иерархические инструкции для агента, кастомные команды, хуки, MCP-сервера, SDK, запуск как фонового агента в GitHub и т.д.
Запускать его можно хоть в терминале, хоть в IDE, хоть на удаленном сервере, хоть как часть какого-то пайплайна и т.п.
Короче, если вы фанатеете по настройке систем под себя и креативному использованию инструментов - однозначно затянет :)
#ai #development #cc
В последние пару месяцев в стане пользователей Cursor наблюдается оживленное броуновское движение, переходящее в массовый исход.
Причины понятны: внезапные смены прайсинга и неявные лимиты подкосили доверие к компании.
Штош, рынок не терпит пустоты.
Куда идти? Я перепробовал несколько разных инструментов и на текущий момент остановился на связке Claude Code + Cursor.
Сейчас их использование для кода у меня разделяется так:
● создание проекта с нуля и массовая кодогенерация - Claude Code
● изменения в небольшом-среднем проекте - Claude Code
● фоновый агент - Claude Code
● изменения в большом проекте, который не готов к AI-кодингу - Cursor
● быстрые фиксы - Cursor
● использование моделей других вендоров - Cursor
● рефакторинг - JetBrains IDEs (внезапно), руками
Плюсы Claude Code в сравнении с Cursor
🟢 Лучше работает с тулзами
Что, впрочем, неудивительно, т.к. и модели, и сам инструмент от одной компании и разработчики смогли качественно запромптить модель, раскрыв её агентский потенциал
🟢 Моделям доступен полный контекст
Ну т.е. все 200к, в отличие от Cursor, где в не-MAX режиме у Sonnet доступно 128k (Opus доступен только в MAX-режиме в Cursor).
🟢 Качественнее управление контекстом
Cursor активно экономит контекст (жмёт, обрезает, выкидывает куски), т.к. по сути ему не выгодно тратить на вас много токенов.
Claude Code не так стеснён в трате токенов, и может себе позволить не вмешиваться сильно в контекст.
Плюс, за счёт использования субагентов есть возможность задействовать несколько независимых полных контекстов в рамках одного запроса.
🟢 Лучше следует плану
По умолчанию и сам строит план с тудушками, и сам ему следует, причём редко когда теряет какие-то пункты.
Планам, которые вы ему дали, тоже следует точнее, чем агент в Cursor.
Тут пара вещей, я думаю, работает - с одной стороны более качественный промптинг на следование инструкциям, а с другой - по мере выполнения этапов плана Claude Code обновляет статус задач и вставляет их список снова и снова в контекст, закрепляя следование намеченному плану.
🟢 Дольше тащит многоэтапные задачи
Это является следствием из всех предыдущих пунктов.
20+ минут - не редкость, а на каких-то широких задачах и больше часа может возиться.
Тем не менее, я бы не делал из этого соревнование по выносливости, т.к. с увеличением времени и сложности задачи агент может идти вразнос, так что задачи с прицелом на долгую работу надо подбирать соответствующие - попроще и параллелизуемые.
🟢 Консольный интерфейс
Мы вообще-то в 2025м и интерфейс Claude Code выглядит довольно... эмм..., весело, всё двигается и играет неземная музыка.
Ну т.е. консоль, да, но вполне современная консоль, насыщенная всякими мелкими визуализациями и шорткатами (которые обязательно надо заранее изучить).
Плюс, много возможностей по кастомизации Claude Code под свои задачи и процессы, включая иерархические инструкции для агента, кастомные команды, хуки, MCP-сервера, SDK, запуск как фонового агента в GitHub и т.д.
Запускать его можно хоть в терминале, хоть в IDE, хоть на удаленном сервере, хоть как часть какого-то пайплайна и т.п.
Короче, если вы фанатеете по настройке систем под себя и креативному использованию инструментов - однозначно затянет :)
#ai #development #cc
1👍13🔥11❤5🤩1
Claude Code (2/2)
Недостатки тоже есть, и, хоть они не помешали включению Claude Code в мои процессы, стоит про них знать, как и про способы с ними справляться.
Минусы Claude Code в сравнении с Cursor
🔴 Консольный интерфейс
Нельзя посмотреть/отредактировать код, принять/отклонить изменения, что-то порефакторить и т.п.
Решается просто - в дополнение нужна IDE, к тому же есть простенькие интеграции с VS Code-based и JetBrains IDEs.
🔴 Нет чекпойнтов
Удобная фича Cursor тут отсутствует в принципе, к предыдущему состоянию кода не вернуться, просто промотав историю в чате.
Есть ряд костылей разного качества, но ни один из них не дотягивает до того, как это сделано в Cursor.
Получается, самое трушное - это git branch + (опционально, worktree) + commit после получения ответа агента + squash merge, и с какой-нить автоматизацией, чтобы не делать это каждый раз руками.
Пробовал ещё Claudia и ccundo, но нет, это всё сырые штуки.
🔴 Модели только от Anthropic
Ну т.е. натравить o3/Gemini легко на какую-то проблему не выйдет.
Так что Cursor у меня остается в качестве как IDE, так и второго агента :)
🔴 Нет собственного индекса проекта
Агенту приходится пользоваться базовыми инструментами сбора релевантного контекста каждый раз в новом чате.
Это долго, может засорять контекст и не всегда находит всё нужное.
Решения пока что такие:
● использовать субагентов для предварительного сбора контекста (если у вас проект не на 10м токенов, конечно) - они в параллель довольно качественно просмотрят проект по кускам;
● завести свой
● Memory Bank-like методология ведения документации по проекту.
И обязательно нужно использовать Plan Mode для планирования задач в большой кодовой базе, ревьювить план, и в случае чего руками подкидывать контекст агенту или посылать его изучать релевантные места проекта.
🟡 Дороже?
И да, и нет - за $20 в месяц на плане Pro вы получаете возможность довольно активно пользоваться Sonnet в течение примерно часа каждые 5 часов (лимиты форсятся в рамках 5-часовых сессий).
В сравнимом MAX-режиме в Cursor за час можно легко потратить больше.
А в обычном режиме см. вышеперечисленные плюсы Claude Code, и есть вероятность упереться в заранее неизвестные лимиты в Cursor.
По наблюдениям и личному опыту, после дозы за $20 практически неизбежен переход на один из Max-планов.
В плане Max за $100 даётся ограниченный доступ к Opus и довольно сложно достижимый лимит по работе с Sonnet.
Для проектирования чего-то в Opus и кодогенерации при помощи Sonnet получается комфортно.
А в плане Max за $200 лимиты и Opus становятся весьма щедрыми.
Увы, в Claude Code тоже нет какой-то индикации "маны", кроме предупреждения о том, что приближается лимит в рамках текущей сессии.
И это, кстати, тоже создает возможность динамического изменения как лимитов, так и длины контекста со стороны Anthropic.
А, и да, эти лимиты шарятся с https://claude.ai, Claude Desktop и Claude Code GitHub Actions, которые тоже можно использовать в рамках общей подписки.
Что почитать/посмотреть
Для преодоления кривой обучения стоит потратить 1-2 часа и вдумчиво ознакомиться с базой:
● Mastering Claude Code in 30 minutes - доклад от одного из создателей (Бориса, который успел сходить поработать в Cursor и уже вернулся обратно в Anthropic, пока я собирался писать этот пост :))
● Claude Code in Action - официальный мини-курс по Claude Code от Anthropic
● Claude Code: Best practices for agentic coding - статья с хорошими и не всегда очевидными практиками использования Claude Code
Этот набор ресурсов вам даст больше, чем знает 99%+ пользователей Claude Code :)
#ai #development #cc
Недостатки тоже есть, и, хоть они не помешали включению Claude Code в мои процессы, стоит про них знать, как и про способы с ними справляться.
Минусы Claude Code в сравнении с Cursor
🔴 Консольный интерфейс
Нельзя посмотреть/отредактировать код, принять/отклонить изменения, что-то порефакторить и т.п.
Решается просто - в дополнение нужна IDE, к тому же есть простенькие интеграции с VS Code-based и JetBrains IDEs.
🔴 Нет чекпойнтов
Удобная фича Cursor тут отсутствует в принципе, к предыдущему состоянию кода не вернуться, просто промотав историю в чате.
Есть ряд костылей разного качества, но ни один из них не дотягивает до того, как это сделано в Cursor.
Получается, самое трушное - это git branch + (опционально, worktree) + commit после получения ответа агента + squash merge, и с какой-нить автоматизацией, чтобы не делать это каждый раз руками.
Пробовал ещё Claudia и ccundo, но нет, это всё сырые штуки.
🔴 Модели только от Anthropic
Ну т.е. натравить o3/Gemini легко на какую-то проблему не выйдет.
Так что Cursor у меня остается в качестве как IDE, так и второго агента :)
🔴 Нет собственного индекса проекта
Агенту приходится пользоваться базовыми инструментами сбора релевантного контекста каждый раз в новом чате.
Это долго, может засорять контекст и не всегда находит всё нужное.
Решения пока что такие:
● использовать субагентов для предварительного сбора контекста (если у вас проект не на 10м токенов, конечно) - они в параллель довольно качественно просмотрят проект по кускам;
● завести свой
CLAUDE.md в каждой папке/модуле проекта, который требует описания своего внутреннего устройства и указать там, какие ещё сабмодули лежат ниже в иерархии;● Memory Bank-like методология ведения документации по проекту.
И обязательно нужно использовать Plan Mode для планирования задач в большой кодовой базе, ревьювить план, и в случае чего руками подкидывать контекст агенту или посылать его изучать релевантные места проекта.
🟡 Дороже?
И да, и нет - за $20 в месяц на плане Pro вы получаете возможность довольно активно пользоваться Sonnet в течение примерно часа каждые 5 часов (лимиты форсятся в рамках 5-часовых сессий).
В сравнимом MAX-режиме в Cursor за час можно легко потратить больше.
А в обычном режиме см. вышеперечисленные плюсы Claude Code, и есть вероятность упереться в заранее неизвестные лимиты в Cursor.
По наблюдениям и личному опыту, после дозы за $20 практически неизбежен переход на один из Max-планов.
В плане Max за $100 даётся ограниченный доступ к Opus и довольно сложно достижимый лимит по работе с Sonnet.
Для проектирования чего-то в Opus и кодогенерации при помощи Sonnet получается комфортно.
А в плане Max за $200 лимиты и Opus становятся весьма щедрыми.
Увы, в Claude Code тоже нет какой-то индикации "маны", кроме предупреждения о том, что приближается лимит в рамках текущей сессии.
И это, кстати, тоже создает возможность динамического изменения как лимитов, так и длины контекста со стороны Anthropic.
А, и да, эти лимиты шарятся с https://claude.ai, Claude Desktop и Claude Code GitHub Actions, которые тоже можно использовать в рамках общей подписки.
Что почитать/посмотреть
Для преодоления кривой обучения стоит потратить 1-2 часа и вдумчиво ознакомиться с базой:
● Mastering Claude Code in 30 minutes - доклад от одного из создателей (Бориса, который успел сходить поработать в Cursor и уже вернулся обратно в Anthropic, пока я собирался писать этот пост :))
● Claude Code in Action - официальный мини-курс по Claude Code от Anthropic
● Claude Code: Best practices for agentic coding - статья с хорошими и не всегда очевидными практиками использования Claude Code
Этот набор ресурсов вам даст больше, чем знает 99%+ пользователей Claude Code :)
#ai #development #cc
🔥37👍17❤10🤝4
Claude Code - субагенты и кастомные агенты
Субагенты в Claude Code (CC) существуют уже давно, но были мало кому известны, да и в документации про них была всего пара упоминаний.
И вот на днях Anthropic официально анонсировали поддержку кастомных агентов, которые реализованы поверх субагентов.
Разберемся и в том, и в другом.
1️⃣ Субагенты
Их можно воспринимать как потоки исполнения внутри CC, каждый со своим изолированным контекстом, инструментами и специализированным системным промптом.
Для делегации задачи основной агент использует инструмент Task для запуска субагента и передаёт ему промпт и нужный для задачи контекст.
Что это даёт?
🟢 Экономия контекста
К примеру, поиск по большому количеству файлов в основном диалоге забьёт контекст содержимым всех этих файлов.
В случае же запуска субагента в основной контекст попадёт только суммаризированный результат его работы
🟢 Ускорение за счёт параллелизма
Если нужно провести рефакторинг вширь по проекту - говорим CC использовать субагентов для этой задачи и получаем существенное ускорение
🟢 Более долгие задачи
Когда подзадачи делаются субагентами, основной агент может "вести" задачи с бОльшим количеством шагов, экономя собственный контекст - а именно его ограниченность сильно влияет на размер задачи, с которой может справиться агент
Для чего использовать?
● "суммаризация":
* сбор сведений для документации
* ответы на вопросы по проекту
● параллелизуемые "широкие" задачи:
* несложный рефакторинг
* code review / security review
● там, где важно иметь в общем контексте результат, а не процесс работы:
* запуск тестов
* анализ логов
Как запустить?
Да прям словами сказать:
Стоит помнить, что, т.к. это промптинг, да и не все задачи хорошо ложатся на субагентов, CC не всегда их запускает.
Бороться с его планировщиком, тем не менее, не очень продуктивно.
2️⃣ Кастомные агенты
Это новая фича - по сути, поддержка специализации для субагентов:
1. пишем
2. создаём себе техлида, ревьювера, безопасника,ковбой-кодера, чайка-менеджера под свои предпочтения
3. работаем с ними как с командой :)
Конфигурация
Каждый из кастомных агентов определяется md-файлом с YAML frontmatter с такими полями:
* name - идентификатор агента
* description - подсказка Claude, когда использовать этого агента
* tools - опциональный список доступных инструментов
А в теле файла - инструкции для этого агента и его "личность".
Эти файлы живут либо в
Как запустить?
● Автоматическое делегирование - СС сам делегирует работу, когда думает, что задача подходит под описание кастомного агента
● Явный вызов - к примеру,
● Цепочки агентов - можно их чейнить:
Ограничения
❌ Нет встроенного механизма для прямого общения между субагентами - всё идет через основного агента, но народ активно городит костыли в виде общих файлов / MCP
❌ Нельзя выбрать модель для кастомного агента - это было бы весьма логично, но пока нельзя, и народ активно просит :)
Хорошие практики
● Чёткие роли - лучше создавать агентов с чёткой ответственностью вместо универсальных
● Учитывайте ограничения подписки - субагенты могут жечь много токенов, особенно при работе в параллель, так что можно быстрее упереться в лимиты
● Проверки в длинных цепочках - если вы чейните кастомных агентов, то старайтесь проверять результаты их работы после каждого шага, иногда даже прям своими глазами 😱
● Ограничивайте инструменты - давайте кастомному агенту только те инструменты, которые ему нужны - это и безопаснее, и удерживает агента от лишних действий
● Экспериментируйте - фича новая, так что сообщество сейчас активно осваивает и изобретает сценарии использования, и это отличное время для экспериментов и обмена интересными практиками :)
#ai #development #cc
Субагенты в Claude Code (CC) существуют уже давно, но были мало кому известны, да и в документации про них была всего пара упоминаний.
И вот на днях Anthropic официально анонсировали поддержку кастомных агентов, которые реализованы поверх субагентов.
Разберемся и в том, и в другом.
1️⃣ Субагенты
Их можно воспринимать как потоки исполнения внутри CC, каждый со своим изолированным контекстом, инструментами и специализированным системным промптом.
Для делегации задачи основной агент использует инструмент Task для запуска субагента и передаёт ему промпт и нужный для задачи контекст.
Что это даёт?
🟢 Экономия контекста
К примеру, поиск по большому количеству файлов в основном диалоге забьёт контекст содержимым всех этих файлов.
В случае же запуска субагента в основной контекст попадёт только суммаризированный результат его работы
🟢 Ускорение за счёт параллелизма
Если нужно провести рефакторинг вширь по проекту - говорим CC использовать субагентов для этой задачи и получаем существенное ускорение
🟢 Более долгие задачи
Когда подзадачи делаются субагентами, основной агент может "вести" задачи с бОльшим количеством шагов, экономя собственный контекст - а именно его ограниченность сильно влияет на размер задачи, с которой может справиться агент
Для чего использовать?
● "суммаризация":
* сбор сведений для документации
* ответы на вопросы по проекту
● параллелизуемые "широкие" задачи:
* несложный рефакторинг
* code review / security review
● там, где важно иметь в общем контексте результат, а не процесс работы:
* запуск тестов
* анализ логов
Как запустить?
Да прям словами сказать:
use subagents for this task, можно это даже в CLAUDE.md добавить.Стоит помнить, что, т.к. это промптинг, да и не все задачи хорошо ложатся на субагентов, CC не всегда их запускает.
Бороться с его планировщиком, тем не менее, не очень продуктивно.
2️⃣ Кастомные агенты
Это новая фича - по сути, поддержка специализации для субагентов:
1. пишем
/agents - запускается визард2. создаём себе техлида, ревьювера, безопасника,
3. работаем с ними как с командой :)
Конфигурация
Каждый из кастомных агентов определяется md-файлом с YAML frontmatter с такими полями:
* name - идентификатор агента
* description - подсказка Claude, когда использовать этого агента
* tools - опциональный список доступных инструментов
А в теле файла - инструкции для этого агента и его "личность".
Эти файлы живут либо в
~/.claude/agents/ для пользовательских агентов, либо в .claude/agents/ проекта для проектно-специфичных.Как запустить?
● Автоматическое делегирование - СС сам делегирует работу, когда думает, что задача подходит под описание кастомного агента
● Явный вызов - к примеру,
Use the test-runner subagent to run all tests and report failures● Цепочки агентов - можно их чейнить:
First use the code-analyzer subagent to find performance issues, then use the optimizer subagent to fix themОграничения
❌ Нет встроенного механизма для прямого общения между субагентами - всё идет через основного агента, но народ активно городит костыли в виде общих файлов / MCP
❌ Нельзя выбрать модель для кастомного агента - это было бы весьма логично, но пока нельзя, и народ активно просит :)
Хорошие практики
● Чёткие роли - лучше создавать агентов с чёткой ответственностью вместо универсальных
● Учитывайте ограничения подписки - субагенты могут жечь много токенов, особенно при работе в параллель, так что можно быстрее упереться в лимиты
● Проверки в длинных цепочках - если вы чейните кастомных агентов, то старайтесь проверять результаты их работы после каждого шага, иногда даже прям своими глазами 😱
● Ограничивайте инструменты - давайте кастомному агенту только те инструменты, которые ему нужны - это и безопаснее, и удерживает агента от лишних действий
● Экспериментируйте - фича новая, так что сообщество сейчас активно осваивает и изобретает сценарии использования, и это отличное время для экспериментов и обмена интересными практиками :)
#ai #development #cc
3👍21🔥10❤5👏2
Vibe Coding in Prod и деревья с листьями
Попался доклад Эрика Шлунца из Anthropic - "Vibe coding in prod".
Название довольно кликбейтное, потому что я думал, что щас он запустит Claude Code на каком-нить продакшн-сервере и начнет там вайб-кодить :)
(кроме шуток, такое тоже практикуется, но надо очень хорошо представлять себе, куда вы жмав)
Но нет, доклад оказался довольно взвешенным и хорошо описывает несколько базовых практик, которых обязательно нужно придерживаться:
—
🟢 Будьте PM'ом для ИИ: вместо коротких команд, готовьте для агента полноценное ТЗ, как для нового джуна в команде. Чем больше контекста и чётче задача - тем лучше результат.
🟢 Вам нужно думать о "стволе" и "ветвях", а не о "листьях": делегируйте ИИ реализацию конечных, изолированных модулей ("листьев" на дереве зависимостей), но оставляйте за собой проектирование ядра системы ("ствола" и "ветвей").
🟢 Обеспечьте верифицируемость: ваша задача - создать условия, в которых результат работы ИИ можно легко и надёжно проверить. Это могут быть тесты, чётко определённые входные/выходные данные или другие формы верификации.
🟢 Помните об экспоненте: возможности ИИ растут нелинейно. График от METR, который показал Эрик, наглядно демонстрирует, что сложность задач, решаемых ИИ, удваивается каждые 7 месяцев. Нужно готовиться к миру, где ИИ сможет выполнять работу, на которую сегодня уходят недели или месяцы.
Кстати, тот график подробнее описан в серии постов про сценарий AI 2027.
—
Листья и деревья
Идея про "листья" показалась мне особенно полезной - она просто и наглядно формулирует то, к чему мы уже пришли в ИИ-разработке.
Вообще, с точки зрения старших технических специалистов, этот подход не нов - одной из их задач всегда была проработка архитектуры и фиксация высокоуровневых абстракций.
А имея прочный базис, можно было безопасно делегировать реализацию конкретных фич, снижая риски и не накапливая критический техдолг.
Почему это важно?
● Техдолг в "листьях" не так страшен. Их можно относительно дёшево переписать, если что-то пойдет не так, ведь от них мало что зависит.
● Техдолг в ядре системы - это проблема. Закрывать его больно, долго и дорого, вплоть до того, что может оказаться, что проще всё переписать.
Будущую расширяемость и поддерживаемость очень сложно оценить - "человеческая" индустрия разработки так и не выработала надёжных стандартов, хотя попыток было много.
Так что при разработке с ИИ возникает похожее разделение, и наша роль смещается в сторону проектирования надёжного базиса, который мы хорошо понимаем.
Что это значит на практике
⚪️ Высокоуровневая архитектура должна оставаться под контролем
Мы должны подробно проработать основные компоненты, их взаимодействие, контракты и API. Вся эта информация должна быть зафиксирована в виде, понятном для ИИ (документация, схемы, интерфейсы и т.п.).
Чем более нестандартную систему вы делаете - тем более детальный нужен контроль, - просто в силу того, что ИИ лучше справляется с распространенными подходами.
⚪️ Реализация "листьев" делегируется ИИ
Имея чёткие внешние контракты и набор тестов, мы можем отпустить контроль над тем, как именно реализован конкретный изолированный модуль.
Можно всегда его переписать при помощи ИИ с нуля, если потребуется, и пока тесты и прочие верификации проходят, нас даже не особо волнует его внутренняя реализация.
⚪️ Вопрос гранулярности
Насколько большим может быть "лист"? Сейчас надёжной метрики у нас нет, это определяется эмпирически и зависит от проекта, используемой модели и инструментария.
Но стоит понимать, что с ростом возможностей моделей, "листом" может стать целый сервис.
А мы поднимаемся всё выше по уровням абстракции, двигаясь от кода к системной архитектуре, фичам, продукту.
#ai #architecture #development
Попался доклад Эрика Шлунца из Anthropic - "Vibe coding in prod".
Название довольно кликбейтное, потому что я думал, что щас он запустит Claude Code на каком-нить продакшн-сервере и начнет там вайб-кодить :)
(кроме шуток, такое тоже практикуется, но надо очень хорошо представлять себе, куда вы жмав)
Но нет, доклад оказался довольно взвешенным и хорошо описывает несколько базовых практик, которых обязательно нужно придерживаться:
—
🟢 Будьте PM'ом для ИИ: вместо коротких команд, готовьте для агента полноценное ТЗ, как для нового джуна в команде. Чем больше контекста и чётче задача - тем лучше результат.
🟢 Вам нужно думать о "стволе" и "ветвях", а не о "листьях": делегируйте ИИ реализацию конечных, изолированных модулей ("листьев" на дереве зависимостей), но оставляйте за собой проектирование ядра системы ("ствола" и "ветвей").
🟢 Обеспечьте верифицируемость: ваша задача - создать условия, в которых результат работы ИИ можно легко и надёжно проверить. Это могут быть тесты, чётко определённые входные/выходные данные или другие формы верификации.
🟢 Помните об экспоненте: возможности ИИ растут нелинейно. График от METR, который показал Эрик, наглядно демонстрирует, что сложность задач, решаемых ИИ, удваивается каждые 7 месяцев. Нужно готовиться к миру, где ИИ сможет выполнять работу, на которую сегодня уходят недели или месяцы.
Кстати, тот график подробнее описан в серии постов про сценарий AI 2027.
—
Листья и деревья
Идея про "листья" показалась мне особенно полезной - она просто и наглядно формулирует то, к чему мы уже пришли в ИИ-разработке.
Вообще, с точки зрения старших технических специалистов, этот подход не нов - одной из их задач всегда была проработка архитектуры и фиксация высокоуровневых абстракций.
А имея прочный базис, можно было безопасно делегировать реализацию конкретных фич, снижая риски и не накапливая критический техдолг.
Почему это важно?
● Техдолг в "листьях" не так страшен. Их можно относительно дёшево переписать, если что-то пойдет не так, ведь от них мало что зависит.
● Техдолг в ядре системы - это проблема. Закрывать его больно, долго и дорого, вплоть до того, что может оказаться, что проще всё переписать.
Будущую расширяемость и поддерживаемость очень сложно оценить - "человеческая" индустрия разработки так и не выработала надёжных стандартов, хотя попыток было много.
Так что при разработке с ИИ возникает похожее разделение, и наша роль смещается в сторону проектирования надёжного базиса, который мы хорошо понимаем.
Что это значит на практике
⚪️ Высокоуровневая архитектура должна оставаться под контролем
Мы должны подробно проработать основные компоненты, их взаимодействие, контракты и API. Вся эта информация должна быть зафиксирована в виде, понятном для ИИ (документация, схемы, интерфейсы и т.п.).
Чем более нестандартную систему вы делаете - тем более детальный нужен контроль, - просто в силу того, что ИИ лучше справляется с распространенными подходами.
⚪️ Реализация "листьев" делегируется ИИ
Имея чёткие внешние контракты и набор тестов, мы можем отпустить контроль над тем, как именно реализован конкретный изолированный модуль.
Можно всегда его переписать при помощи ИИ с нуля, если потребуется, и пока тесты и прочие верификации проходят, нас даже не особо волнует его внутренняя реализация.
⚪️ Вопрос гранулярности
Насколько большим может быть "лист"? Сейчас надёжной метрики у нас нет, это определяется эмпирически и зависит от проекта, используемой модели и инструментария.
Но стоит понимать, что с ростом возможностей моделей, "листом" может стать целый сервис.
А мы поднимаемся всё выше по уровням абстракции, двигаясь от кода к системной архитектуре, фичам, продукту.
#ai #architecture #development
4🔥30👍23❤5👏2
Уровни внедрения ИИ в разработку v2
Так, ну что, настало время обновить классификацию, уже 7 месяцев прошло с первой версии.
Disclaimer: уровни довольно условные и скорее нужно их воспринимать как то, насколько далеко мы от ручной работы с кодом.
0. Изоляция
Ну, кажется, не осталось программистов, которые ничего не слышали про использование ИИ в разработке.
Но если встретите таких - не спугните, это же как йети, с ними крайне интересно познакомиться :)
1. Сниппетинг
Использование сайтов ChatGPT/DeepSeek для написания мелких скриптов/функций от случая к случаю
2. Копипастинг
Систематическая разработка при помощи ИИ через копипастинг кода между каким-то UI к LLM и своей IDE.
Ускоряется в несколько раз износ Ctrl/C/V (ну или Ctrl/Shift/Insert, у членов древнего секретного ордена).
Кстати, сюда же попадает использование Repomix / Prompt Tower для склейки файлов проекта в один и отправки в AI Studio, к примеру, где у Gemini есть хороший 1м контекст.
3. Автодополнение
Использование одного лишь ИИ-автодополнения в процессе написания кода руками в своей IDE - собственно с этого всё и началось, когда вышел GitHub Copilot аж 300 лет тому назад (ну, ~3.5 года, если быть точнее,я был там, Гендальф).
4. AI IDE
Когда в IDE используется чат с LLM и/или агент: Cursor / Windsurf / RooCode / Cline.
В них можно интерактивно общаться с LLM и давать ей небольшие задачи для автономного выполнения, а LLM как часть агента уже сама найдёт нужный код в проекте, сама его поправит, сама выловит ошибки, и потом покажет diff, который можно поревьюить.
А ещё с этого уровня у нас появляются MCP, правила для агентов, простенькая память и проблематика контекста (если что, см. воркшоп, там про контекст много).
5. CLI-агенты
Отказываемся от GUI, переходим в консоль и кастомизируем агента под свои нужды и процессы: Claude Code, Codex CLI, Gemini CLI, etc, со своими плюсами и минусами в сравнении с IDE.
Здесь же появляются кастомные команды, субагенты и разнообразные workflows, в которых агент, пишущий код - лишь часть общего процесса.
6. Фоновые агенты и агенты полного цикла
Тут у нас Codex Cloud, Google Jules, GitHub Copilot coding agent и даже Cursor Background Agent как фоновые агенты в облаках, и работающие в основном с GitHub.
А также Devin / OpenHands - они способны в условном Slack принять от вас задачу, зададут вопросы, сходят в Git, залезут в базу знаний проекта, напишут код, потестят его, запушат и передадут на ревью,получат зарплату.
Между этими изначально двумя разными видами систем идёт конвергенция и, думаю, какой-то их гибрид сильно повлияет на будущее разработки.
7. (Secret Level)
Встречаются специальные маньяки, которые пишут свои мультиагентные системы под задачи разработки целых проектов.
Задачи у них тоже довольно специальные, но, как правило, интересные и весьма нетривиальные.
Здесь постепенно зарождается свой набор инструментария для высокоуровневой работы, который в перспективе может заменить привычные нам интерфейсы и позволит оркестрировать множество разнородных агентов.
У меня сейчас такое распределение получается в задачах разработки:
● 80% - №5, CLI-агенты с кастомными workflows
● 10% - №6, фоновые агенты для задач, которые случается делать не за рабочим местом
● 10% - №7, исследования по оркестрации мультиагентных систем
А как у вас обстоят дела (см. голосование дальше)?
—
Напоминаю про нашу конфу по AI-разработке во вторник, 14го!
🔜 ai-dev.live 🔙
#ai #development
Так, ну что, настало время обновить классификацию, уже 7 месяцев прошло с первой версии.
Disclaimer: уровни довольно условные и скорее нужно их воспринимать как то, насколько далеко мы от ручной работы с кодом.
0. Изоляция
Ну, кажется, не осталось программистов, которые ничего не слышали про использование ИИ в разработке.
Но если встретите таких - не спугните, это же как йети, с ними крайне интересно познакомиться :)
1. Сниппетинг
Использование сайтов ChatGPT/DeepSeek для написания мелких скриптов/функций от случая к случаю
2. Копипастинг
Систематическая разработка при помощи ИИ через копипастинг кода между каким-то UI к LLM и своей IDE.
Ускоряется в несколько раз износ Ctrl/C/V (ну или Ctrl/Shift/Insert, у членов древнего секретного ордена).
Кстати, сюда же попадает использование Repomix / Prompt Tower для склейки файлов проекта в один и отправки в AI Studio, к примеру, где у Gemini есть хороший 1м контекст.
3. Автодополнение
Использование одного лишь ИИ-автодополнения в процессе написания кода руками в своей IDE - собственно с этого всё и началось, когда вышел GitHub Copilot аж 300 лет тому назад (ну, ~3.5 года, если быть точнее,
4. AI IDE
Когда в IDE используется чат с LLM и/или агент: Cursor / Windsurf / RooCode / Cline.
В них можно интерактивно общаться с LLM и давать ей небольшие задачи для автономного выполнения, а LLM как часть агента уже сама найдёт нужный код в проекте, сама его поправит, сама выловит ошибки, и потом покажет diff, который можно поревьюить.
А ещё с этого уровня у нас появляются MCP, правила для агентов, простенькая память и проблематика контекста (если что, см. воркшоп, там про контекст много).
5. CLI-агенты
Отказываемся от GUI, переходим в консоль и кастомизируем агента под свои нужды и процессы: Claude Code, Codex CLI, Gemini CLI, etc, со своими плюсами и минусами в сравнении с IDE.
Здесь же появляются кастомные команды, субагенты и разнообразные workflows, в которых агент, пишущий код - лишь часть общего процесса.
6. Фоновые агенты и агенты полного цикла
Тут у нас Codex Cloud, Google Jules, GitHub Copilot coding agent и даже Cursor Background Agent как фоновые агенты в облаках, и работающие в основном с GitHub.
А также Devin / OpenHands - они способны в условном Slack принять от вас задачу, зададут вопросы, сходят в Git, залезут в базу знаний проекта, напишут код, потестят его, запушат и передадут на ревью,
Между этими изначально двумя разными видами систем идёт конвергенция и, думаю, какой-то их гибрид сильно повлияет на будущее разработки.
7. (Secret Level)
Встречаются специальные маньяки, которые пишут свои мультиагентные системы под задачи разработки целых проектов.
Задачи у них тоже довольно специальные, но, как правило, интересные и весьма нетривиальные.
Здесь постепенно зарождается свой набор инструментария для высокоуровневой работы, который в перспективе может заменить привычные нам интерфейсы и позволит оркестрировать множество разнородных агентов.
У меня сейчас такое распределение получается в задачах разработки:
● 80% - №5, CLI-агенты с кастомными workflows
● 10% - №6, фоновые агенты для задач, которые случается делать не за рабочим местом
● 10% - №7, исследования по оркестрации мультиагентных систем
А как у вас обстоят дела (см. голосование дальше)?
—
Напоминаю про нашу конфу по AI-разработке во вторник, 14го!
#ai #development
Please open Telegram to view this post
VIEW IN TELEGRAM
4👍25❤24🔥10👏2💩1