Ползучий фичеризм
(creeping featurism)
Это такая распространенная болезнь в разработке программного обеспечения, которая поражает многих фаундеров и продактов, заключающаяся в том, что всегда хочется добавить больше фич в продукт, чем реально нужно пользователям(да кто бы их ещё спрашивал) , при этом медленно, но верно усложняя его до состояния полной непригодности.
Откуда оно берётся?
* конкуренция на рынке создает впечатление того, что нужно впихнуть в продукт больше фич, нежели сделать качественно самые важные;
* желание угодить всем пользователям, даже если это твой близкий родственник, безусловную поддержку которого ты принял за реальную потребность в новой фиче;
* "мы можем это добавить, почему бы и нет?" - почему бы и не смешать огурцы с молоком и запить пивом?;
* попытка оправдать высокую стоимость продукта - "а мы ещё вот так можем, хоба!";
* так делают все успешные компании - ну да, ну да, самое время пытаться в точности повторить путь компании, которая была основана 20 лет назад, а сейчас имеет миллионы клиентов и миллиарды свободных денег для экспериментов.
Какие вызывает проблемы
* откладывание выпуска продукта в свет - будем в него добрасывать фич, пока всё не сложится под собственным весом или не кончатся деньги;
* сложность использования - "как это непонятно, ну всё же просто, нужно вот тут подпрыгнуть, здесь зацепиться, дальше вскарабкаться до 3-го этажа, сделать сальто на карниз влево и вот же форточка, чтобы попасть домой";
* всё тормозит - ну да, пока этот космический корабль взлетит, половина пользователей уже словит острую дофаминовую недостаточность.
Как бороться?
1. Задаться такими простыми вопросами:
* а это точно решает проблему пользователя?
* вы уверены, что это не ваша личная хотелка?
* не лучше ли улучшить/починить то, что уже есть?
2. Ввести правило "один вошёл - один вышел".
Ну т.е. хотите добавить новую фичу? Отлично! Какую старую удалим?
В особо запущенных случаях можно делать размен не 1:1, а 1:2, а то даже и 1:3.
3. Устроить фича-детокс.
Пара спринтов без новых фич. Улучшаем то, что есть, а еще лучше - удаляем то, чем уже никто не пользуется.
И главное правило тут в том, что пользователям нужна не куча фич, а нужно решение их проблем.
Аналоги не из IT
Организация праздников
Что добавили: тематическая вечеринка в стиле стимпанк с костюмированным шоу и приглашенными актерами и фуршетом.
Что реально было нужно: собраться за одним столом с друзьями, заказать пиццу и поболтать.
Кулинария
Что добавили: молекулярная гастрономия, три вида соуса, съедобное золото, авторская подача.
Что реально было нужно: горячая еда, поданная вовремя.
Зубная щётка
Что добавили: bluetooth-подключение, анализ движений, 3D-карта полости рта, геймификация чистки.
Что реально было нужно: чистить зубы 2 минуты.
Планирование отпуска
Что добавили: детальный поминутный план на 2 недели с посещением 20 достопримечательностей в день.
Что реально было нужно: выспаться и полежать на пляже.
Кот
Что добавили: эко-домик с лежанкой, подогревом и WiFi, гаджет для удаленной игры с мобильным приложением.
Что реально было нужно: картонная коробка и мятый фантик на веревочке.
Сталкивались с чем-то подобным? :)
#it #product
(creeping featurism)
Это такая распространенная болезнь в разработке программного обеспечения, которая поражает многих фаундеров и продактов, заключающаяся в том, что всегда хочется добавить больше фич в продукт, чем реально нужно пользователям
Откуда оно берётся?
* конкуренция на рынке создает впечатление того, что нужно впихнуть в продукт больше фич, нежели сделать качественно самые важные;
* желание угодить всем пользователям, даже если это твой близкий родственник, безусловную поддержку которого ты принял за реальную потребность в новой фиче;
* "мы можем это добавить, почему бы и нет?" - почему бы и не смешать огурцы с молоком и запить пивом?;
* попытка оправдать высокую стоимость продукта - "а мы ещё вот так можем, хоба!";
* так делают все успешные компании - ну да, ну да, самое время пытаться в точности повторить путь компании, которая была основана 20 лет назад, а сейчас имеет миллионы клиентов и миллиарды свободных денег для экспериментов.
Какие вызывает проблемы
* откладывание выпуска продукта в свет - будем в него добрасывать фич, пока всё не сложится под собственным весом или не кончатся деньги;
* сложность использования - "как это непонятно, ну всё же просто, нужно вот тут подпрыгнуть, здесь зацепиться, дальше вскарабкаться до 3-го этажа, сделать сальто на карниз влево и вот же форточка, чтобы попасть домой";
* всё тормозит - ну да, пока этот космический корабль взлетит, половина пользователей уже словит острую дофаминовую недостаточность.
Как бороться?
1. Задаться такими простыми вопросами:
* а это точно решает проблему пользователя?
* вы уверены, что это не ваша личная хотелка?
* не лучше ли улучшить/починить то, что уже есть?
2. Ввести правило "один вошёл - один вышел".
Ну т.е. хотите добавить новую фичу? Отлично! Какую старую удалим?
В особо запущенных случаях можно делать размен не 1:1, а 1:2, а то даже и 1:3.
3. Устроить фича-детокс.
Пара спринтов без новых фич. Улучшаем то, что есть, а еще лучше - удаляем то, чем уже никто не пользуется.
И главное правило тут в том, что пользователям нужна не куча фич, а нужно решение их проблем.
Аналоги не из IT
Организация праздников
Что добавили: тематическая вечеринка в стиле стимпанк с костюмированным шоу и приглашенными актерами и фуршетом.
Что реально было нужно: собраться за одним столом с друзьями, заказать пиццу и поболтать.
Кулинария
Что добавили: молекулярная гастрономия, три вида соуса, съедобное золото, авторская подача.
Что реально было нужно: горячая еда, поданная вовремя.
Зубная щётка
Что добавили: bluetooth-подключение, анализ движений, 3D-карта полости рта, геймификация чистки.
Что реально было нужно: чистить зубы 2 минуты.
Планирование отпуска
Что добавили: детальный поминутный план на 2 недели с посещением 20 достопримечательностей в день.
Что реально было нужно: выспаться и полежать на пляже.
Кот
Что добавили: эко-домик с лежанкой, подогревом и WiFi, гаджет для удаленной игры с мобильным приложением.
Что реально было нужно: картонная коробка и мятый фантик на веревочке.
Сталкивались с чем-то подобным? :)
#it #product
😁5🔥3❤2💯1
ChatGPT o1
Сегодня OpenAI в рамках своего марафона "12 дней OpenAI", где они будут рассказывать про новинки, представили полноценный релиз своей модели, ориентированной на размышления, ChatGPT o1.
Чем она отличается от "обычных" моделей?
Принципиальное её отличие от предыдущих моделей, таких как GPT-4o, в том, что она заточена на "раздумья": o1 формирует пошаговые размышления, строя логические цепочки, что напоминает работу системы 2 мышления, описанного Даниэлем Канеманом в "Думай медленно… решай быстро":
Модели, выпущенные ранее, выдавали результат моментально, но при этом поверхностный и с большей вероятностью галлюцинаций.
o1 же перед тем, как ответить, некоторое время "думает" - т.е. пошагово, в несколько заходов, формирует ответ.
Популярно объясняя, это похоже на то, как и мы не сразу выдаем решение какой-то сложной задачи, а раскладываем ее на составляющие и решаем поэтапно, используя результаты предыдущих размышлений для того, чтобы двигаться дальше.
Для каких задач она нужна?
* решение сложных проблем в научных исследованиях, программировании, математике;
* построение планов, декомпозиция, проектирование, архитектура ПО;
* помощь в обучении и разборе сложных тем.
Некоторые результаты этой модели
Программирование: На Международной олимпиаде по информатике (IOI) 2024 года ChatGPT o1 продемонстрировала результаты, ставящие её на 49-е место, а на платформе Codeforces (олимпиадное программирование) превзошла 89% участников, что свидетельствует о её высоких навыках в решении сложных алгоритмических задач.
Математика: В квалификационном этапе Американской математической олимпиады (AIME) модель "вошла" в число 500 лучших студентов США, демонстрируя глубокое понимание математических концепций.
Научные дисциплины: ChatGPT o1 показала результаты на уровне PhD в тестах по физике, биологии и химии, что делает её полезным инструментом для исследователей и учёных.
Цены
Помимо o1, которая сейчас входит в план за $20 в месяц, была представлена и o1 Pro, которая входит в план уже за $200 в месяц, но по сути является той же o1, которой даётся возможность думать дольше, потребляя тем самым больше вычислительных ресурсов.
Конкуренция
Ну и надо понимать, что OpenAI не уникальны в плане построения подобного рода моделей.
Китайская Alibaba на днях выпустила свою экспериментальную QwQ - тоже "размышляющую" модель, которая и в разы меньше, и при этом свободно распространяемая.
Хоть она и похуже по некоторым тестам, чем o1, но, учитывая все остальные факторы, можно говорить о том, что технологический разрыв минимален.
#ai #news
Сегодня OpenAI в рамках своего марафона "12 дней OpenAI", где они будут рассказывать про новинки, представили полноценный релиз своей модели, ориентированной на размышления, ChatGPT o1.
Чем она отличается от "обычных" моделей?
Принципиальное её отличие от предыдущих моделей, таких как GPT-4o, в том, что она заточена на "раздумья": o1 формирует пошаговые размышления, строя логические цепочки, что напоминает работу системы 2 мышления, описанного Даниэлем Канеманом в "Думай медленно… решай быстро":
Система 1 — быстрая, автоматическая, интуитивная, не требует усилий. Работает на ассоциациях, подходит для привычных задач и мгновенных реакций.
Система 2 — медленная, осознанная, требует концентрации и усилий. Используется для анализа, логических рассуждений и решения сложных задач.
Модели, выпущенные ранее, выдавали результат моментально, но при этом поверхностный и с большей вероятностью галлюцинаций.
o1 же перед тем, как ответить, некоторое время "думает" - т.е. пошагово, в несколько заходов, формирует ответ.
Популярно объясняя, это похоже на то, как и мы не сразу выдаем решение какой-то сложной задачи, а раскладываем ее на составляющие и решаем поэтапно, используя результаты предыдущих размышлений для того, чтобы двигаться дальше.
Для каких задач она нужна?
* решение сложных проблем в научных исследованиях, программировании, математике;
* построение планов, декомпозиция, проектирование, архитектура ПО;
* помощь в обучении и разборе сложных тем.
Некоторые результаты этой модели
Программирование: На Международной олимпиаде по информатике (IOI) 2024 года ChatGPT o1 продемонстрировала результаты, ставящие её на 49-е место, а на платформе Codeforces (олимпиадное программирование) превзошла 89% участников, что свидетельствует о её высоких навыках в решении сложных алгоритмических задач.
Математика: В квалификационном этапе Американской математической олимпиады (AIME) модель "вошла" в число 500 лучших студентов США, демонстрируя глубокое понимание математических концепций.
Научные дисциплины: ChatGPT o1 показала результаты на уровне PhD в тестах по физике, биологии и химии, что делает её полезным инструментом для исследователей и учёных.
Цены
Помимо o1, которая сейчас входит в план за $20 в месяц, была представлена и o1 Pro, которая входит в план уже за $200 в месяц, но по сути является той же o1, которой даётся возможность думать дольше, потребляя тем самым больше вычислительных ресурсов.
Конкуренция
Ну и надо понимать, что OpenAI не уникальны в плане построения подобного рода моделей.
Китайская Alibaba на днях выпустила свою экспериментальную QwQ - тоже "размышляющую" модель, которая и в разы меньше, и при этом свободно распространяемая.
Хоть она и похуже по некоторым тестам, чем o1, но, учитывая все остальные факторы, можно говорить о том, что технологический разрыв минимален.
#ai #news
👍4🔥3❤🔥1
300 недель
Тут Zwift (виртуальный веломир) на днях выдал, что у меня стрик в 53 недели активностей, ну т.е. в течение года каждую неделю у меня была минимум одна тренировка/гонка.
"Хм", подумал я, "а должно быть больше - они же эту фичу со стриками только год назад добавили".
Полез смотреть... И правда, не 53, а 300 недель бега, велика, аштанги, тренажерки и всякого по мелочи :)
Это включая ковиды, гриппы, отпуска, травмы, обострения, авралы и прочие отговорки.
Но в целом это неплохо, т.к. создает некоторый стержень, вокруг которого выстраивается здоровье, питание, режим, воля, эмоциональная стабильность.
К примеру, я не могу себе позволить в тренировочный день пропустить обед или нажраться какой-нить безумной хоботни, а уж тем более неизвестной еды (да-да, это ещё хуже безумной хоботни).
Не дам нервной системе разболтаться в течение дня, если вечером тренировка, т.к. это скажется на её результатах.
Я буду спать 7-8+ часов, даже если мне кажется, что мне не хочется, или есть какие-то более важные дела.
А если в планах гонка или сложная тренировка, всё это нужно соблюдать за несколько дней до неё.
Тут есть и возвратный эффект - в какой-то момент просто перестает хотеться есть то, что мешает тренировкам, автоматом естся то, что им помогает; психика стабилизируется, т.к. излишки энергии есть куда потратить (а они сами собой образуются, если заниматься); режим дня тоже так просто не сломаешь и т.п.
Причем это как-то на автомате происходит, я уже не ощущаю, что на тренировочный процесс тратятся какие-то ресурсы. Оно просто... надо, и поэтому делается.
Да и в целом хуже себя чувствую, если пропускаю тренировку, чем если все-таки чем-то позанимаюсь.
Плюс, за это время, стартовав с нуля, удалось приблизиться к нормативам КМС по велоспорту - мелочь, а приятно :)
Тут, конечно, было бы модно организовать какой-нить марафон достижения целей, а? :)
Или порассуждать о самоиндентификации: а кто же я после этого - айтишник али кто-то ещё, но камон, все мы кто-то ещё, да и вообще самоидентичность - штука флюидная(хожу по тонкому льду, хехе) .
Шучу-шучу, но что-то могу и буду иногда писать по теме :)
—
Прошлые посты про спорт:
* Спорт - это не инвестиция
* Про остановку старения в будущем
* Типы удовольствия
#sport #flex
Тут Zwift (виртуальный веломир) на днях выдал, что у меня стрик в 53 недели активностей, ну т.е. в течение года каждую неделю у меня была минимум одна тренировка/гонка.
"Хм", подумал я, "а должно быть больше - они же эту фичу со стриками только год назад добавили".
Полез смотреть... И правда, не 53, а 300 недель бега, велика, аштанги, тренажерки и всякого по мелочи :)
Это включая ковиды, гриппы, отпуска, травмы, обострения, авралы и прочие отговорки.
Но в целом это неплохо, т.к. создает некоторый стержень, вокруг которого выстраивается здоровье, питание, режим, воля, эмоциональная стабильность.
К примеру, я не могу себе позволить в тренировочный день пропустить обед или нажраться какой-нить безумной хоботни, а уж тем более неизвестной еды (да-да, это ещё хуже безумной хоботни).
Не дам нервной системе разболтаться в течение дня, если вечером тренировка, т.к. это скажется на её результатах.
Я буду спать 7-8+ часов, даже если мне кажется, что мне не хочется, или есть какие-то более важные дела.
А если в планах гонка или сложная тренировка, всё это нужно соблюдать за несколько дней до неё.
Тут есть и возвратный эффект - в какой-то момент просто перестает хотеться есть то, что мешает тренировкам, автоматом естся то, что им помогает; психика стабилизируется, т.к. излишки энергии есть куда потратить (а они сами собой образуются, если заниматься); режим дня тоже так просто не сломаешь и т.п.
Причем это как-то на автомате происходит, я уже не ощущаю, что на тренировочный процесс тратятся какие-то ресурсы. Оно просто... надо, и поэтому делается.
Да и в целом хуже себя чувствую, если пропускаю тренировку, чем если все-таки чем-то позанимаюсь.
Тут, конечно, было бы модно организовать какой-нить марафон достижения целей, а? :)
Или порассуждать о самоиндентификации: а кто же я после этого - айтишник али кто-то ещё, но камон, все мы кто-то ещё, да и вообще самоидентичность - штука флюидная
Шучу-шучу, но что-то могу и буду иногда писать по теме :)
—
Прошлые посты про спорт:
* Спорт - это не инвестиция
* Про остановку старения в будущем
* Типы удовольствия
#sport #flex
👍5🔥5❤🔥3🎉3😱1
Прочитал новость об очередном чемпионате мира по Excel.
Сразу подумал - а не было ли попыток решать эти задачи при помощи AI?
Я за какой-то год видел задания всех уровней - там прям весьма жёстко местами.
Странно, что нашелся всего один чувак, но нашелся! :)
https://www.youtube.com/watch?v=_StGAVK30D0
https://www.youtube.com/watch?v=cw1nsZI60V8
https://www.youtube.com/watch?v=UDYPr8pux28
он тут в каждом из видео решает по задаче с соревнования при помощи Copilot в Excel.
Задания выбрал простые (и с ними Copilot успешно справился), и непонятно, будет ли решать дальше, т.к. дальше задачи интереснее.
Но даже те, которые он решил, уже могут стать проблемой для пользователя-обывателя :)
#news #ai
Сразу подумал - а не было ли попыток решать эти задачи при помощи AI?
Я за какой-то год видел задания всех уровней - там прям весьма жёстко местами.
Странно, что нашелся всего один чувак, но нашелся! :)
https://www.youtube.com/watch?v=_StGAVK30D0
https://www.youtube.com/watch?v=cw1nsZI60V8
https://www.youtube.com/watch?v=UDYPr8pux28
он тут в каждом из видео решает по задаче с соревнования при помощи Copilot в Excel.
Задания выбрал простые (и с ними Copilot успешно справился), и непонятно, будет ли решать дальше, т.к. дальше задачи интереснее.
Но даже те, которые он решил, уже могут стать проблемой для пользователя-обывателя :)
#news #ai
👍5❤🔥3
Многомерный конструктор
На уровне большого проекта или компании метрика по тому, кто нужен для того, чтобы какая-то инициатива состоялась, по сути, одномерная: "нам нужно 10 человек, 100 или 1000". Называется просто число, и никто не спрашивает, что это за 100 людей и что они будут делать.
Если спускаться с уровня топ-менеджмента, картинка начинает обрастать деталями: появляются дизайнеры, разработчики, QA, менеджмент среднего звена.
Дальше - больше: фронтендеры, бекендеры, спецы по C#, Angular, джуны, сеньоры и т.п. На этом уровне всё ещё довольно просто, хотя и уже начинают проскакивать нюансы того, как всех этих людей со своими слабыми и сильными сторонами собрать в нечто устойчивое.
Но когда доходишь до уровня конкретной команды, начинается самое интересное. Уже недостаточно просто взять ещё одного бекендера или закрыть пробел с помощью QA. Нужно учесть массу особенностей каждого человека: характер, темп работы, любовь к порядку или хаосу, опыт, стиль общения.
Сложность резко повышается, а процесс сбора и слаживания команды превращается в многомерный конструктор:
* в нем есть десяток-другой "измерений", по которым можно оценивать людей;
* существует разнообразие ролей в команде, в каждой из которых нужно определенное сочетание "метрик" по этим измерениям;
* требуется минимально допустимая общая "сумма" по каждой из метрик на всю команду;
* в межчеловеческом взаимодействии рождаются какие-то дополнительные эффекты и метрики, которые нужно учитывать;
* некоторые из людей демонстрируют совершенно уникальные свойства.
Какие выводы из этого можно сделать?
* люди на уровне конкретной команды - это не просто абстрактные "ресурсы";
* одни и те же люди в разных командах могут раскрываться совершенно по-разному;
* правильный найм требует гибкости и отхода от шаблонов;
* оптимальный баланс в команде чаще важнее, чем отдельные индивидуумы;
* хороший управленец обязан уметь мыслить на разных уровнях, понимая, когда стоит оперировать простыми числами, а когда уже пора браться за многомерное конструирование.
В общем, приходится иногда довольно много думать и действовать совсем не по учебнику, но это-то и самое интересное :)
#work #management
На уровне большого проекта или компании метрика по тому, кто нужен для того, чтобы какая-то инициатива состоялась, по сути, одномерная: "нам нужно 10 человек, 100 или 1000". Называется просто число, и никто не спрашивает, что это за 100 людей и что они будут делать.
Если спускаться с уровня топ-менеджмента, картинка начинает обрастать деталями: появляются дизайнеры, разработчики, QA, менеджмент среднего звена.
Дальше - больше: фронтендеры, бекендеры, спецы по C#, Angular, джуны, сеньоры и т.п. На этом уровне всё ещё довольно просто, хотя и уже начинают проскакивать нюансы того, как всех этих людей со своими слабыми и сильными сторонами собрать в нечто устойчивое.
Но когда доходишь до уровня конкретной команды, начинается самое интересное. Уже недостаточно просто взять ещё одного бекендера или закрыть пробел с помощью QA. Нужно учесть массу особенностей каждого человека: характер, темп работы, любовь к порядку или хаосу, опыт, стиль общения.
Сложность резко повышается, а процесс сбора и слаживания команды превращается в многомерный конструктор:
* в нем есть десяток-другой "измерений", по которым можно оценивать людей;
* существует разнообразие ролей в команде, в каждой из которых нужно определенное сочетание "метрик" по этим измерениям;
* требуется минимально допустимая общая "сумма" по каждой из метрик на всю команду;
* в межчеловеческом взаимодействии рождаются какие-то дополнительные эффекты и метрики, которые нужно учитывать;
* некоторые из людей демонстрируют совершенно уникальные свойства.
Какие выводы из этого можно сделать?
* люди на уровне конкретной команды - это не просто абстрактные "ресурсы";
* одни и те же люди в разных командах могут раскрываться совершенно по-разному;
* правильный найм требует гибкости и отхода от шаблонов;
* оптимальный баланс в команде чаще важнее, чем отдельные индивидуумы;
* хороший управленец обязан уметь мыслить на разных уровнях, понимая, когда стоит оперировать простыми числами, а когда уже пора браться за многомерное конструирование.
В общем, приходится иногда довольно много думать и действовать совсем не по учебнику, но это-то и самое интересное :)
#work #management
👍6💯5❤2
Про ценообразование.
Тут недавно у перспективного AI-редактора Windsurf интересно с ценами получилось: сначала, когда только они выпустились недели 2-3 назад, все, сидя на 2-недельном триале удивлялись, как это так, что они подписку по 10 баксов буду продавать - мол, дешево на фоне прямого конкурента, Cursor, подписка у которого стоит $20.
Потом разработчики Windsurf, видимо, всё посчитали, слегка офигели от нагрузки и расходов и подняли стоимость подписки до $15.
Тут уже в ответ офигели пользователи, так что для "старичков" (которые, напоминаю, максимум 3 недели назад начали пользоваться продуктом) вернули подписку за 10 баксов.
А сегодня совсем другая компания, Devin, объявила о доступности своего "AI-инженера" за ... $500 в месяц :)
Ну ладно-ладно, это всё-таки продукт другого уровня, т.к. способен на себя брать задачи не только написания кода, но и работы с таск-трекером, репозиториями, может тестировать написанный код и в целом позиционируется как ваш персональный джун.
Но явно AI-компании перестаются мелочиться с ценами - то вот подписка на ChatGPT Pro за $200, то вот теперь джун за $500.
Самое интересное тут то, насколько эти цены себя в итоге оправдают, но Devin руки чешутся попробовать :)
#ai #news
Тут недавно у перспективного AI-редактора Windsurf интересно с ценами получилось: сначала, когда только они выпустились недели 2-3 назад, все, сидя на 2-недельном триале удивлялись, как это так, что они подписку по 10 баксов буду продавать - мол, дешево на фоне прямого конкурента, Cursor, подписка у которого стоит $20.
Потом разработчики Windsurf, видимо, всё посчитали, слегка офигели от нагрузки и расходов и подняли стоимость подписки до $15.
Тут уже в ответ офигели пользователи, так что для "старичков" (которые, напоминаю, максимум 3 недели назад начали пользоваться продуктом) вернули подписку за 10 баксов.
А сегодня совсем другая компания, Devin, объявила о доступности своего "AI-инженера" за ... $500 в месяц :)
Ну ладно-ладно, это всё-таки продукт другого уровня, т.к. способен на себя брать задачи не только написания кода, но и работы с таск-трекером, репозиториями, может тестировать написанный код и в целом позиционируется как ваш персональный джун.
Но явно AI-компании перестаются мелочиться с ценами - то вот подписка на ChatGPT Pro за $200, то вот теперь джун за $500.
Самое интересное тут то, насколько эти цены себя в итоге оправдают, но Devin руки чешутся попробовать :)
#ai #news
👍6🔥2👏1
🤖 Что такое Devin?
Почитал официальную инфу, посмотрел на то, как это работает и первые мнения в сети, и вот что могу сказать на текущий момент ⬇️
Это ассистент на базе ИИ, который может взять на себя рутинные задачи разработчиков. Например, с его помощью можно:
✅ исправить баги (особенно мелкие баги на фронтенде или edge-case);
✅ создать черновой pull request для задачи из бэклога;
✅ сделать локальный рефакторинг через расширение для VSCode.
Devin интегрируется через Slack как основной интерфейс.
Через IDE (VSCode) можно напрямую работать с его pull requests. Это может быть полезно для задач вроде рефакторинга, работы с API или базовой документации.
Тут можно глянуть, как выглядит работа с ним: https://www.youtube.com/@Cognition-Labs/videos
💰Подписка стоит от $500 в месяц.
Судя по инфе из пресс-релиза, нет ограничений по количеству пользователей, т.е. оптимальнее его брать сразу на команду, нежели на одного разработчика.
Это в том числе оправдывает такую стоимость - явно расчет на компании.
Советы для эффективной работы от самих разработчиков Devin:
🔹 лучше всего поручать задачи, которые вы сами знаете, как решить.
🔹 предоставляйте требования заранее, объясните, как проверять результат, и давайте обратную связь для обучения Devin.
🔹 для крупных задач разбейте работу на короткие сессии до трёх часов.
Эти советы в равной степени применимы и к Windsurf/Cursor.
🐞Отмечается, что хотя Devin и может справляться с рутинной работой, вам, скорее всего, придётся корректировать результат, особенно в случаях сложных изменений или конфликтов при слиянии кода.
Не зря они его позиционируют скорее как джуна по подписке :)
Что интересно, Devin активно тестируют в "дикой природе". Например, он уже отметился в нескольких известных open-source проектах:
🔸 Anthropic MCP: Devin справился с решением проблемы, которую сообщил пользователь, разобрав спецификацию MCP в браузере. В первой сессии он нашёл корень проблемы, а затем протестировал изменения end-to-end. Хотя результат не был идеальным, мейнмейнеры оставили фидбек, который помог довести правки до ума во второй сессии. Первая сессия, вторая сессия, PR.
🔸 Zod: Devin добавил новую фичу в библиотеку и даже написал тесты.
🔸 Google: помог с обработкой HTTP ошибок в Go-клиенте Github.
🔸 Llama Index: исправил баг с неправильным использованием токенизатора.
🔸 Karpathy’s nanoGPT: написал скрипт для тестирования небольшой правки в коде.
В итоге, мое мнение такое: пока что не вижу революции, это скорее эволюция, идущая дальше Windsurf/Cursor, но становится очевидно, что за такими вот агентскими системами, интегрированными во всю вертикаль разработки - будущее.
Официальный пресс-релиз: https://www.cognition.ai/blog/devin-generally-available
#ai #news
Почитал официальную инфу, посмотрел на то, как это работает и первые мнения в сети, и вот что могу сказать на текущий момент ⬇️
Это ассистент на базе ИИ, который может взять на себя рутинные задачи разработчиков. Например, с его помощью можно:
✅ исправить баги (особенно мелкие баги на фронтенде или edge-case);
✅ создать черновой pull request для задачи из бэклога;
✅ сделать локальный рефакторинг через расширение для VSCode.
Devin интегрируется через Slack как основной интерфейс.
Через IDE (VSCode) можно напрямую работать с его pull requests. Это может быть полезно для задач вроде рефакторинга, работы с API или базовой документации.
Тут можно глянуть, как выглядит работа с ним: https://www.youtube.com/@Cognition-Labs/videos
💰Подписка стоит от $500 в месяц.
Судя по инфе из пресс-релиза, нет ограничений по количеству пользователей, т.е. оптимальнее его брать сразу на команду, нежели на одного разработчика.
Это в том числе оправдывает такую стоимость - явно расчет на компании.
Советы для эффективной работы от самих разработчиков Devin:
🔹 лучше всего поручать задачи, которые вы сами знаете, как решить.
🔹 предоставляйте требования заранее, объясните, как проверять результат, и давайте обратную связь для обучения Devin.
🔹 для крупных задач разбейте работу на короткие сессии до трёх часов.
Эти советы в равной степени применимы и к Windsurf/Cursor.
🐞Отмечается, что хотя Devin и может справляться с рутинной работой, вам, скорее всего, придётся корректировать результат, особенно в случаях сложных изменений или конфликтов при слиянии кода.
Не зря они его позиционируют скорее как джуна по подписке :)
Что интересно, Devin активно тестируют в "дикой природе". Например, он уже отметился в нескольких известных open-source проектах:
🔸 Anthropic MCP: Devin справился с решением проблемы, которую сообщил пользователь, разобрав спецификацию MCP в браузере. В первой сессии он нашёл корень проблемы, а затем протестировал изменения end-to-end. Хотя результат не был идеальным, мейнмейнеры оставили фидбек, который помог довести правки до ума во второй сессии. Первая сессия, вторая сессия, PR.
🔸 Zod: Devin добавил новую фичу в библиотеку и даже написал тесты.
🔸 Google: помог с обработкой HTTP ошибок в Go-клиенте Github.
🔸 Llama Index: исправил баг с неправильным использованием токенизатора.
🔸 Karpathy’s nanoGPT: написал скрипт для тестирования небольшой правки в коде.
В итоге, мое мнение такое: пока что не вижу революции, это скорее эволюция, идущая дальше Windsurf/Cursor, но становится очевидно, что за такими вот агентскими системами, интегрированными во всю вертикаль разработки - будущее.
Официальный пресс-релиз: https://www.cognition.ai/blog/devin-generally-available
#ai #news
🔥6👾6❤5
Тут в одном из каналов задали вопрос, а как у кого с практикой использования AI в работе.
Рассказываю, какие штуки используются у нас:
* транскрибирование звонков, потому что с текстом потом куда проще управляться;
* выделение задач из транскриптов: определение, в чем состоят задачи, кому назначены и насколько срочны — это, кстати, ещё и требует структурности и четкости в проведении встреч;
* извлечение знаний: создание статей для внутренней базы знаний о проекте или для более полной формулировки задач;
* просто постановка задач голосом: преобразование речи в текст и оформление задачи для таск-трекера;
* обсуждение архитектурных решений по проекту: например, тот же o1 неплохо справляется с этой задачей;
* разбиение задач на подзадачи, с учётом специфики backend/frontend/devops/etc;
* создание скриптов и утилит: такие задачки, занимавшие раньше 1-2 дня, теперь укладывается в 1-2 часа;
* написание кода: для мелких проектов вообще практически весь код пишет AI, для проектов покрупнее всё равно экономит от 30 до 50% времени, если правильно его готовить;
* несложная аналитика: построение выводов из данных, работа с SQL, Jupyter Notebooks и т.п.;
* перевод видео: перевод полезных курсов с английского на русский, включая субтитры и озвучку;
* создание промптов для AI: само собой, при помощи AI :)
Для чего ещё хочется использовать:
* онлайн-перевод звонков: перевод идущего звонка в реальном времени с языка на язык;
* интеграция документации в чаты с AI: автоматическое "подмешивание" информации из документации проекта в чат для повышения релевантности обсуждений;
* построение отчетов: автоматизация сбора и анализа изменений из таск-трекера/Git для создания отчетов — чтобы можно было отвечать на такие вопросы, как “что произошло за последний месяц в определенной команде” или "как изменился определенный функционал";
* сопровождение звонков информацией: предоставление релевантной теме идущего звонка информации из базы знаний;
* проведение мозговых штурмов при помощи агентов с разными ролями (продакт, пользователь, разработчик, тестировщик и т.п.);
* актуализация базы знаний: использование агентов для обновления документации на основе меняющихся требований.
Все эти штуки пока что не повсеместны, и, как и везде, есть свои староверы, но с течением времени улучшаются как инструменты, так и растёт степень знакомства людей с технологиями, так что вектор развития в целом ясен.
Своя специфика у нас в том, что мы не используем сторонние готовые продукты, только API вендоров типа ChatGPT или Claude, а также локальные модели, поверх которых строятся собственные решения. Оно может и не так вылизано, зато кастомизировано под наши нужды и может быть дополнено/изменено когда захочется.
Ну и оно по фану, чего уж там :)
#ai #work
Рассказываю, какие штуки используются у нас:
* транскрибирование звонков, потому что с текстом потом куда проще управляться;
* выделение задач из транскриптов: определение, в чем состоят задачи, кому назначены и насколько срочны — это, кстати, ещё и требует структурности и четкости в проведении встреч;
* извлечение знаний: создание статей для внутренней базы знаний о проекте или для более полной формулировки задач;
* просто постановка задач голосом: преобразование речи в текст и оформление задачи для таск-трекера;
* обсуждение архитектурных решений по проекту: например, тот же o1 неплохо справляется с этой задачей;
* разбиение задач на подзадачи, с учётом специфики backend/frontend/devops/etc;
* создание скриптов и утилит: такие задачки, занимавшие раньше 1-2 дня, теперь укладывается в 1-2 часа;
* написание кода: для мелких проектов вообще практически весь код пишет AI, для проектов покрупнее всё равно экономит от 30 до 50% времени, если правильно его готовить;
* несложная аналитика: построение выводов из данных, работа с SQL, Jupyter Notebooks и т.п.;
* перевод видео: перевод полезных курсов с английского на русский, включая субтитры и озвучку;
* создание промптов для AI: само собой, при помощи AI :)
Для чего ещё хочется использовать:
* онлайн-перевод звонков: перевод идущего звонка в реальном времени с языка на язык;
* интеграция документации в чаты с AI: автоматическое "подмешивание" информации из документации проекта в чат для повышения релевантности обсуждений;
* построение отчетов: автоматизация сбора и анализа изменений из таск-трекера/Git для создания отчетов — чтобы можно было отвечать на такие вопросы, как “что произошло за последний месяц в определенной команде” или "как изменился определенный функционал";
* сопровождение звонков информацией: предоставление релевантной теме идущего звонка информации из базы знаний;
* проведение мозговых штурмов при помощи агентов с разными ролями (продакт, пользователь, разработчик, тестировщик и т.п.);
* актуализация базы знаний: использование агентов для обновления документации на основе меняющихся требований.
Все эти штуки пока что не повсеместны, и, как и везде, есть свои староверы, но с течением времени улучшаются как инструменты, так и растёт степень знакомства людей с технологиями, так что вектор развития в целом ясен.
Своя специфика у нас в том, что мы не используем сторонние готовые продукты, только API вендоров типа ChatGPT или Claude, а также локальные модели, поверх которых строятся собственные решения. Оно может и не так вылизано, зато кастомизировано под наши нужды и может быть дополнено/изменено когда захочется.
Ну и оно по фану, чего уж там :)
#ai #work
Telegram
Уставший техдир
Сижу пишу драфт тем для FrontendConf, в UX и DX драматически много зон, где можно получить буст от GenAI в разработке.
Накиньте, чо у вас по практике использования AI в работе? Как вы пользуетесь, насколько системно? Вы сами приносите с собой инструменты…
Накиньте, чо у вас по практике использования AI в работе? Как вы пользуетесь, насколько системно? Вы сами приносите с собой инструменты…
🔥14👏3❤2🤔1
Разработчики-староверы
"Страшно, очень страшно! Мы не знаем, что это такое, если б мы знали что это такое, но мы не знаем, что это такое" - примерно так начинаются беседы с разработчикам-староверами, которые сознательно отрекаются от всего нового, что в конечном итоге экономит кучу времени.
Вот ну казалось бы, уж где-где, а в нашей профессии быть на острие прогресса и уметь быстро переучиваться - одни из самых важных качеств, а вот поди ж ты.
На моей памяти мы это уже проходили много раз:
От машинного кода к языкам высокого уровня
"Assembler? Да он идеальный! Никакие ваши C мне не нужны!"
Потом приходят первые компиляторы и внезапно оказывается, что писать логику в несколько раз быстрее, чем вручную управлять регистрами.
(и это я еще перфокарты не застал, там наверняка были свои любители ползать в коридоре по распечаткам дампов для дебага)
Поисковики
"В смысле поальтависти? Вот же, у меня документация распечатана" (достает очки для чтения и слюнявит палец).
Интегрированные среды разработки
"Зачем IDE? У меня есть Far Manager и мышечная память!"
А потом смотрят, как коллега при помощи нескольких шорткатов автоматически импортирует нужные зависимости, ошибки подсвечиваются в реальном времени, и есть куча возможностей по упрощению рефакторинга.
(ну ладно, Far я до сих использую, это на всю жизнь 💘)
Системы контроля версий
"Контроль версий? У нас есть папка с названием final_final2_v3."
"Какие конфликты? Вот у нас чатик в аське, мы тут договариваемся, кто какой файл меняет."
Автокомплит
"Я и сам помню все свои классы и методы, плюс всю стандартную библиотеку, зачем мне подсказывать? Это для слабаков!"
Через неделю: "Как там назывался этот метод? MapToEntity? EntityToMap?"
Причём ведь ещё и испытывает гордость за то, что может код на Java писать в блокноте :) Хорошо не в бумажном.
—
Ну, вы понимаете, к чему я веду...
Но об этом в следующий раз :)
#work #ai
"Страшно, очень страшно! Мы не знаем, что это такое, если б мы знали что это такое, но мы не знаем, что это такое" - примерно так начинаются беседы с разработчикам-староверами, которые сознательно отрекаются от всего нового, что в конечном итоге экономит кучу времени.
Вот ну казалось бы, уж где-где, а в нашей профессии быть на острие прогресса и уметь быстро переучиваться - одни из самых важных качеств, а вот поди ж ты.
На моей памяти мы это уже проходили много раз:
От машинного кода к языкам высокого уровня
"Assembler? Да он идеальный! Никакие ваши C мне не нужны!"
Потом приходят первые компиляторы и внезапно оказывается, что писать логику в несколько раз быстрее, чем вручную управлять регистрами.
(и это я еще перфокарты не застал, там наверняка были свои любители ползать в коридоре по распечаткам дампов для дебага)
Поисковики
"В смысле поальтависти? Вот же, у меня документация распечатана" (достает очки для чтения и слюнявит палец).
Интегрированные среды разработки
"Зачем IDE? У меня есть Far Manager и мышечная память!"
А потом смотрят, как коллега при помощи нескольких шорткатов автоматически импортирует нужные зависимости, ошибки подсвечиваются в реальном времени, и есть куча возможностей по упрощению рефакторинга.
(ну ладно, Far я до сих использую, это на всю жизнь 💘)
Системы контроля версий
"Контроль версий? У нас есть папка с названием final_final2_v3."
"Какие конфликты? Вот у нас чатик в аське, мы тут договариваемся, кто какой файл меняет."
Автокомплит
"Я и сам помню все свои классы и методы, плюс всю стандартную библиотеку, зачем мне подсказывать? Это для слабаков!"
Через неделю: "Как там назывался этот метод? MapToEntity? EntityToMap?"
Причём ведь ещё и испытывает гордость за то, что может код на Java писать в блокноте :) Хорошо не в бумажном.
—
Ну, вы понимаете, к чему я веду...
Но об этом в следующий раз :)
#work #ai
😁8🔥6💯4❤1👏1
Страхи разработчиков перед ИИ
В продолжение предыдущего поста.
Читаю тут разное в сети и общаюсь с разработчиками на тему внедрения ИИ в работу, так что решил сделать подборку самых распространенных бабаек и того, как с ними справляться.
Это в основном выдержки из, скажем так, "общественного мнения" + личный опыт.
Страх №1: Качество и безопасность кода
"А вдруг ИИ напишет код с ошибками?"
Это, пожалуй, самое частое опасение разработчиков. И оно небезосновательно – ИИ действительно может генерировать код с багами или уязвимостями. Как это можно решить?
Решение:
• используйте ИИ итеративно, а не как волшебную палочку - т.е. не ждите, что код окажется верным с первого раза. Вы же тоже наверняка не можете написать весь код для фичи за один проход;
• тестируйте сгенерированный код так же тщательно, как и написанный вручную - собственно, тесты лучше всегда иметь, чем не иметь (с уважением, ваш КО), а написать их можно тоже с помощью ИИ;
• внедряйте процесс код-ревью для ИИ-генерированного кода - для совсем ленивых, это тоже можно частично делать при помощи ИИ :)
Страх №2: Профессиональная идентичность
"Меня заменят! Я больше не буду нужен как разработчик!"
Этот страх часто маскируется под другие аргументы, но именно он часто лежит в основе сопротивления использованию ИИ.
Да и в целом звучит немного абсурдно - "я не буду пользоваться тем, что может меня заменить". Что?
Решение:
• воспринимайте ИИ как усилитель своих возможностей, а не их замену;
• сравните с другими инструментами, которые сильно повлияли на продуктивность: IDE, StackOverflow – они не заменили разработчиков, а дали им больше удобства и знаний;
• используйте освободившееся время для решения более сложных архитектурных задач.
Перспектива:
Попадались обсуждения того, как опытные разработчики (даже с 30-летним стажем) стали ещё более ценными специалистами благодаря использованию ИИ. Они решают задачи, которые раньше им казались неприступными, и делают это значительно быстрее.
Причем, у опытных разработчиков тут есть свои преимущества - благодаря развитой интуиции не так важно вникать в нюансы работы сотого по счёту фреймворка, решающего по-новому старые проблемы (и добавляющего новых), если код для него может написать ИИ, важнее понимать как это все работает на верхнем уровне и связь компонентов системы между собой.
Страх №3: Потеря контроля и понимания
"Я не буду понимать, как работает код, если его написал ИИ".
Гм, а если другой разработчик написал код, то как быть? :)
Решение:
• начните с простых задач, мелких функций, или того, что вы раньше уже делали "руками";
• всегда просматривайте и разбирайте сгенерированный код;
• задавайте ИИ вопросы о том, как работает его решение и изучайте новые подходы с его помощью;
• просите ИИ написать документацию к нетривиальному функционалу.
Перспектива:
Многие отмечают, что использование ИИ помогло им быстрее осваивать новые технологии и лучше понимать различные подходы к решению задач.
Собственно, и от себя добавлю, что в плане новых знаний щас год за два, а то и за три идёт :)
Взгляд в будущее
Индустрия явно движется к повсеместному использованию ИИ-инструментов.
Это не вопрос "если", это вопрос "когда".
Как показывает опыт, разработчики, которые раньше начинают использовать ИИ, получают значительные преимущества.
Словом, это еще один инструмент, который повышает вашу конкурентоспособность.
И даже если в вашей компании не внедряются такие практики, и складывается ощущение того, что оно никому не нужно - стоит задуматься о конкурентоспособности самой компании :)
Конечно, в итоге важно не то, используете ли вы ИИ, а то, насколько эффективно вы решаете поставленные задачи.
Но как показывает практика, правильное использование ИИ позволяет разработчикам любого уровня стать продуктивнее, не жертвуя качеством кода и профессиональным ростом.
Главное – подойти к этому осознанно и методично.
#work #ai
В продолжение предыдущего поста.
Читаю тут разное в сети и общаюсь с разработчиками на тему внедрения ИИ в работу, так что решил сделать подборку самых распространенных бабаек и того, как с ними справляться.
Это в основном выдержки из, скажем так, "общественного мнения" + личный опыт.
Страх №1: Качество и безопасность кода
"А вдруг ИИ напишет код с ошибками?"
Это, пожалуй, самое частое опасение разработчиков. И оно небезосновательно – ИИ действительно может генерировать код с багами или уязвимостями. Как это можно решить?
Решение:
• используйте ИИ итеративно, а не как волшебную палочку - т.е. не ждите, что код окажется верным с первого раза. Вы же тоже наверняка не можете написать весь код для фичи за один проход;
• тестируйте сгенерированный код так же тщательно, как и написанный вручную - собственно, тесты лучше всегда иметь, чем не иметь (с уважением, ваш КО), а написать их можно тоже с помощью ИИ;
• внедряйте процесс код-ревью для ИИ-генерированного кода - для совсем ленивых, это тоже можно частично делать при помощи ИИ :)
Страх №2: Профессиональная идентичность
"Меня заменят! Я больше не буду нужен как разработчик!"
Этот страх часто маскируется под другие аргументы, но именно он часто лежит в основе сопротивления использованию ИИ.
Да и в целом звучит немного абсурдно - "я не буду пользоваться тем, что может меня заменить". Что?
Решение:
• воспринимайте ИИ как усилитель своих возможностей, а не их замену;
• сравните с другими инструментами, которые сильно повлияли на продуктивность: IDE, StackOverflow – они не заменили разработчиков, а дали им больше удобства и знаний;
• используйте освободившееся время для решения более сложных архитектурных задач.
Перспектива:
Попадались обсуждения того, как опытные разработчики (даже с 30-летним стажем) стали ещё более ценными специалистами благодаря использованию ИИ. Они решают задачи, которые раньше им казались неприступными, и делают это значительно быстрее.
Причем, у опытных разработчиков тут есть свои преимущества - благодаря развитой интуиции не так важно вникать в нюансы работы сотого по счёту фреймворка, решающего по-новому старые проблемы (и добавляющего новых), если код для него может написать ИИ, важнее понимать как это все работает на верхнем уровне и связь компонентов системы между собой.
Страх №3: Потеря контроля и понимания
"Я не буду понимать, как работает код, если его написал ИИ".
Гм, а если другой разработчик написал код, то как быть? :)
Решение:
• начните с простых задач, мелких функций, или того, что вы раньше уже делали "руками";
• всегда просматривайте и разбирайте сгенерированный код;
• задавайте ИИ вопросы о том, как работает его решение и изучайте новые подходы с его помощью;
• просите ИИ написать документацию к нетривиальному функционалу.
Перспектива:
Многие отмечают, что использование ИИ помогло им быстрее осваивать новые технологии и лучше понимать различные подходы к решению задач.
Собственно, и от себя добавлю, что в плане новых знаний щас год за два, а то и за три идёт :)
Взгляд в будущее
Индустрия явно движется к повсеместному использованию ИИ-инструментов.
Это не вопрос "если", это вопрос "когда".
Как показывает опыт, разработчики, которые раньше начинают использовать ИИ, получают значительные преимущества.
Словом, это еще один инструмент, который повышает вашу конкурентоспособность.
И даже если в вашей компании не внедряются такие практики, и складывается ощущение того, что оно никому не нужно - стоит задуматься о конкурентоспособности самой компании :)
Конечно, в итоге важно не то, используете ли вы ИИ, а то, насколько эффективно вы решаете поставленные задачи.
Но как показывает практика, правильное использование ИИ позволяет разработчикам любого уровня стать продуктивнее, не жертвуя качеством кода и профессиональным ростом.
Главное – подойти к этому осознанно и методично.
#work #ai
Telegram
Этихлид
Разработчики-староверы
"Страшно, очень страшно! Мы не знаем, что это такое, если б мы знали что это такое, но мы не знаем, что это такое" - примерно так начинаются беседы с разработчикам-староверами, которые сознательно отрекаются от всего нового, что в…
"Страшно, очень страшно! Мы не знаем, что это такое, если б мы знали что это такое, но мы не знаем, что это такое" - примерно так начинаются беседы с разработчикам-староверами, которые сознательно отрекаются от всего нового, что в…
👍8❤🔥6❤2👾2
Forwarded from эйай ньюз
o3 и o3-mini - разрыв бенчмарков
Это ещё не AGI, но точно SOTA на всём что только можно. Стоимость тоже гигантская - на решение одного единственного таска могут уйти тысячи долларов.
🎓 SOTA результаты по Frontier Math выросли с 2% до 25%.
💻 На SWE-Bench модель набрала 71,7%. Чтобы вы понимали, в этом году стартап смог поднять 200 миллионов долларов с результатами 13,86%.
👨💻 ELO на Codeforces - 2727, в мире всего у 150 человек больше ELO.
🔥На ARC-AGI модель набрала 87,5%, бенчмарк пять лет не могли покорить. Авторы уже партнёрятся с OpenAI чтобы создать вторую версию бенча.
👨🎓 На GPQA и AIME тоже очень хороший прогресс.
Сегодня дают доступ ресёрчерам безопасности к o3-mini, простым смертным доступ к o3-mini дадут в конце января, к o3 чуть позже.
@ai_newz
Это ещё не AGI, но точно SOTA на всём что только можно. Стоимость тоже гигантская - на решение одного единственного таска могут уйти тысячи долларов.
🎓 SOTA результаты по Frontier Math выросли с 2% до 25%.
💻 На SWE-Bench модель набрала 71,7%. Чтобы вы понимали, в этом году стартап смог поднять 200 миллионов долларов с результатами 13,86%.
👨💻 ELO на Codeforces - 2727, в мире всего у 150 человек больше ELO.
🔥На ARC-AGI модель набрала 87,5%, бенчмарк пять лет не могли покорить. Авторы уже партнёрятся с OpenAI чтобы создать вторую версию бенча.
👨🎓 На GPQA и AIME тоже очень хороший прогресс.
Сегодня дают доступ ресёрчерам безопасности к o3-mini, простым смертным доступ к o3-mini дадут в конце января, к o3 чуть позже.
@ai_newz
🔥3👨💻2
эйай ньюз
o3 и o3-mini - разрыв бенчмарков Это ещё не AGI, но точно SOTA на всём что только можно. Стоимость тоже гигантская - на решение одного единственного таска могут уйти тысячи долларов. 🎓 SOTA результаты по Frontier Math выросли с 2% до 25%. 💻 На SWE-Bench…
ChatGPT o3
Сдержанная формулировка: по некоторым, довольно важным тестам, модель o3 продемонстрировала способность к рассуждениям на уровне топовых экспертов в своей области.
Это снимает принципиальные сомнения в том, что ИИ способен достичь человеческого уровня мышления и открывает путь к внедрению ИИ во все области человеческой деятельности, требующие интеллектуальной работы.
Несдержанная формулировка: ААААА!
#ai
Сдержанная формулировка: по некоторым, довольно важным тестам, модель o3 продемонстрировала способность к рассуждениям на уровне топовых экспертов в своей области.
Это снимает принципиальные сомнения в том, что ИИ способен достичь человеческого уровня мышления и открывает путь к внедрению ИИ во все области человеческой деятельности, требующие интеллектуальной работы.
Несдержанная формулировка: ААААА!
#ai
🔥4😁4👍3❤2👏1
Разработка с AI в начале 2025. Выбор IDE (1/2)
С чего начать разработку с помощью ИИ в начале 2025?
Скоро длинные выходные и кто-то наверняка будет что-то пилить в перерывах между отдыхом. Так что сделайте себе подарок и потратьте время на освоение новых подходов :)
Попробую дать срез текущего состояния и того, что сам использую каждый день.
Эта инфа будет полезной в основном для разработчиков, но люди связанных профессий (QA, менеджеры, аналитики) тоже могут попробовать себя.
Про что я могу рассказать: выбор IDE, LLM, практики работы, текущие ограничения, и к чему присматриваться дальше.
Начнем с IDE
Мой выбор: Cursor - это VSCode-based IDE, которая предоставляет удобные возможности по работе с разными ИИ-моделями для написания кода.
Какие задачи решает
* передача контекста для LLM - не нужно заниматься копипастингом между браузером, где открыт ChatGPT/Claude и IDE. Cursor сам ищет и включает нужные файлы в контекст LLM, или дает возможность явно указать, какие файлы нужно включать;
* просмотр и автоматическое применение изменений в самой IDE - вы получаете красивый diff от LLM, который можете принять или отклонить, полностью или частично;
* правильный промптинг под капотом - судя по всему, там куча эвристик и довольно нетривиальный промптинг используется, руками такое самому писать и отлаживать накладно;
* отличное ИИ-автодополнение - если вы предпочитаете писать код руками, то инлайновые подсказки Cursor, пожалуй, сейчас лучшие среди всех подобных инструментов;
* запуск внешних тулов - к примеру, может сам запускать линтер, проверять написанный код и сам его править. Может запускать тесты, консольные команды и сам проект, анализируя output и исправляя найденные ошибки;
* декомпозиция задач - если у вас довольно объемная задача, то она будет декомпозирована и выполнена по шагам;
* возможность принимать ссылки на документацию - если что-то нетривиальное нужно сделать или по какой-то недавно вышедшей либе у LLM пока что нет доков, то можно просто скинуть ссылку - Cursor сам ее распарсит и включит в контекст.
Вариативность режимов работы (в порядке всё большей автономности ИИ в плане написания кода):
* ручное написание кода - всё как обычно в VSCode, только с умным автодополнением;
* режим чата - просто чатимся о текущем открытом файле (+ можно указать какие-то другие), просим что-то небольшое поправить, после исправлений принимаем (или нет) предложенные изменения. Практически как браузер с ChatGPT, но уже в разы удобнее за счет интеграции в IDE;
* режим Composer Normal - принимает на вход описания изменений, которые могут затрагивать сразу много файлов в проекте, к примеру, добавление/изменение фичи или рефакторинг. Cам старается находить все места в проекте, которые нужно изменить (использует поиск или простенький RAG). Но если весь проект влезает в контекст LLM, то лучше сразу все файлы в него включить на старте;
* режим Composer Agent - в основе как Composer Normal, но с агентскими возможностями, такими как запуск внешних инструментов, более надежная декомпозиция задач и выполнение их по шагам. Не требует включения файлов руками, ищет их сам в структуре проекта и при этом стабильнее, чем в Composer Normal.
Что по ценам?
Для начала попробуйте бесплатный аккаунт.
А дальше - $20 в месяц за 500 запросов к моделям ChatGPT (4, 4o) и Claude 3.5 Sonnet, и при желании этот лимит пропорционально увеличивается.
Мне на текущий момент хватает примерно 1000 запросов в месяц.
Claude Opus и ChatGPT o1-like модели оплачиваются отдельно, т.к. они довольно дорогие.
Список моделей постоянно меняется и пополняется, на сайте не успевают обновлять, лучше смотреть в самом Cursor :)
Стоит отметить, что если посчитать экономику, то использование моделей напрямую, через API, а не через Cursor, выходит намного дороже.
Думаю, тут дело в сочетании нескольких факторов:
* использование денег инвесторов для снижения стоимости;
* прямые контракты со скидками с вендорами (OpenAI, Anthropic);
* активное использование своих моделей под капотом, которые, кстати, неплохо работают (тот же автокомплит, к примеру).
С чего начать разработку с помощью ИИ в начале 2025?
Скоро длинные выходные и кто-то наверняка будет что-то пилить в перерывах между отдыхом. Так что сделайте себе подарок и потратьте время на освоение новых подходов :)
Попробую дать срез текущего состояния и того, что сам использую каждый день.
Эта инфа будет полезной в основном для разработчиков, но люди связанных профессий (QA, менеджеры, аналитики) тоже могут попробовать себя.
Про что я могу рассказать: выбор IDE, LLM, практики работы, текущие ограничения, и к чему присматриваться дальше.
Начнем с IDE
Мой выбор: Cursor - это VSCode-based IDE, которая предоставляет удобные возможности по работе с разными ИИ-моделями для написания кода.
Какие задачи решает
* передача контекста для LLM - не нужно заниматься копипастингом между браузером, где открыт ChatGPT/Claude и IDE. Cursor сам ищет и включает нужные файлы в контекст LLM, или дает возможность явно указать, какие файлы нужно включать;
* просмотр и автоматическое применение изменений в самой IDE - вы получаете красивый diff от LLM, который можете принять или отклонить, полностью или частично;
* правильный промптинг под капотом - судя по всему, там куча эвристик и довольно нетривиальный промптинг используется, руками такое самому писать и отлаживать накладно;
* отличное ИИ-автодополнение - если вы предпочитаете писать код руками, то инлайновые подсказки Cursor, пожалуй, сейчас лучшие среди всех подобных инструментов;
* запуск внешних тулов - к примеру, может сам запускать линтер, проверять написанный код и сам его править. Может запускать тесты, консольные команды и сам проект, анализируя output и исправляя найденные ошибки;
* декомпозиция задач - если у вас довольно объемная задача, то она будет декомпозирована и выполнена по шагам;
* возможность принимать ссылки на документацию - если что-то нетривиальное нужно сделать или по какой-то недавно вышедшей либе у LLM пока что нет доков, то можно просто скинуть ссылку - Cursor сам ее распарсит и включит в контекст.
Вариативность режимов работы (в порядке всё большей автономности ИИ в плане написания кода):
* ручное написание кода - всё как обычно в VSCode, только с умным автодополнением;
* режим чата - просто чатимся о текущем открытом файле (+ можно указать какие-то другие), просим что-то небольшое поправить, после исправлений принимаем (или нет) предложенные изменения. Практически как браузер с ChatGPT, но уже в разы удобнее за счет интеграции в IDE;
* режим Composer Normal - принимает на вход описания изменений, которые могут затрагивать сразу много файлов в проекте, к примеру, добавление/изменение фичи или рефакторинг. Cам старается находить все места в проекте, которые нужно изменить (использует поиск или простенький RAG). Но если весь проект влезает в контекст LLM, то лучше сразу все файлы в него включить на старте;
* режим Composer Agent - в основе как Composer Normal, но с агентскими возможностями, такими как запуск внешних инструментов, более надежная декомпозиция задач и выполнение их по шагам. Не требует включения файлов руками, ищет их сам в структуре проекта и при этом стабильнее, чем в Composer Normal.
Что по ценам?
Для начала попробуйте бесплатный аккаунт.
А дальше - $20 в месяц за 500 запросов к моделям ChatGPT (4, 4o) и Claude 3.5 Sonnet, и при желании этот лимит пропорционально увеличивается.
Мне на текущий момент хватает примерно 1000 запросов в месяц.
Claude Opus и ChatGPT o1-like модели оплачиваются отдельно, т.к. они довольно дорогие.
Список моделей постоянно меняется и пополняется, на сайте не успевают обновлять, лучше смотреть в самом Cursor :)
Стоит отметить, что если посчитать экономику, то использование моделей напрямую, через API, а не через Cursor, выходит намного дороже.
Думаю, тут дело в сочетании нескольких факторов:
* использование денег инвесторов для снижения стоимости;
* прямые контракты со скидками с вендорами (OpenAI, Anthropic);
* активное использование своих моделей под капотом, которые, кстати, неплохо работают (тот же автокомплит, к примеру).
👍12🔥3❤1👨💻1
Разработка с AI в начале 2025. Выбор IDE (2/2)
Почему не плагин к моей IDE? Я так к ней привык...
Потому что текущие IDE слишком медленные в плане внедрения изменений, которые требуются для полноценной интеграции ИИ-пайплайнов в процесс написания кода. Разработчикам ИИ-IDEшек проще сделать форк VSCode, чем ждать, пока изменят ядро.
И да, я понимаю, что больно отказываться от IDEшек JetBrains, но вот сейчас дела обстоят так, что сторонние IDE лучше для работы с ИИ.
Но ведь никто не мешает один и тот же проект держать открытым в двух IDE одновременно :)
Почему не Copilot?
Специально выделю его, и скажу, что он, несмотря на недавние обновления, так и застрял в прошлом и к тому же как-то очень нестабильно работает, когда нужно много файлов поменять. Возможно, в следующей итерации поправят, но тогда все равно останется проблема его ограниченности как плагина к IDE.
Почему не Aider/Cline?
Это инструменты, которые больше заточены на написание проектов в автономном режиме, и дают меньше контроля над кодом. Т.е. в том же Cursor, если мне понадобится, я могу всегда нужный код и руками написать, а могу переключиться на Composer Agent.
Плюс, за счет работы напрямую с API LLM-вендоров, они жгут токены довольно активно, и есть истории, когда народ по сотне баксов за день на это умудрялся тратить. В этом плане траты на Cursor предсказуемые и довольно низкие (пока что по крайней мере).
Почему не bolt.new / v0.dev / lovable.dev?
Ну потому что пост от разработчика и в основном для разработчиков :)
И я не люблю последующий потенциальный vendor lock-in, мне нравится всё на своей машине запускать, а потом иметь возможность деплоить куда захочу.
Но! Если у вас таких бзиков нет и вам по большей части нужно сделать именно веб-приложение с простым или отсутствующим бекендом, то советую присмотреться к lovable.dev (и к v0.dev во вторую очередь).
Почему не Windsurf?
Это практически аналог Cursor с упором именно на написание кода в режиме агента, и выпустился он в тот момент, когда у Cursor еще не было Composer Agent.
Но спустя буквально пару недель появился-таки Composer Agent и использование Windsurf потеряло смысл.
Тем не менее, это один из инструментов, к которому стоит присматриваться, т.к. компания, которая его выпустила, обладает большим опытом в плане разработки IDE-тулзов и можно надеяться на то, что Windsurf будет развиваться в правильном направлении.
Почему не Devin?
Потому что $500 в месяц и нацелен сразу на команды. Я про него уже писал, когда он вышел.
Вкратце - это один из вероятных сценариев того, как будет выглядеть будущее командной агентной разработки, но пока что оно не наступило :)
Почему не [yet another tool]...
Потому что столько всего появляется, что не успеваю попробовать :)
Из комментов:
* bolt.dyi - открытая версия bolt.new, можно поставить на свое железо, позволяет работать с большим количеством разных моделей, включая локальные;
* OpenHands (бывший OpenDevin) - открытый аналог Devin, выглядит интересно, в планах попробовать погонять локально.
—
Прошлые посты по связанным темам:
* Разработчики-староверы
* Страхи разработчиков перед ИИ
* Пишем приложение голосом
* Остаточная сложность
* Чёрный ящик
Почему не плагин к моей IDE? Я так к ней привык...
Потому что текущие IDE слишком медленные в плане внедрения изменений, которые требуются для полноценной интеграции ИИ-пайплайнов в процесс написания кода. Разработчикам ИИ-IDEшек проще сделать форк VSCode, чем ждать, пока изменят ядро.
И да, я понимаю, что больно отказываться от IDEшек JetBrains, но вот сейчас дела обстоят так, что сторонние IDE лучше для работы с ИИ.
Но ведь никто не мешает один и тот же проект держать открытым в двух IDE одновременно :)
Почему не Copilot?
Специально выделю его, и скажу, что он, несмотря на недавние обновления, так и застрял в прошлом и к тому же как-то очень нестабильно работает, когда нужно много файлов поменять. Возможно, в следующей итерации поправят, но тогда все равно останется проблема его ограниченности как плагина к IDE.
Почему не Aider/Cline?
Это инструменты, которые больше заточены на написание проектов в автономном режиме, и дают меньше контроля над кодом. Т.е. в том же Cursor, если мне понадобится, я могу всегда нужный код и руками написать, а могу переключиться на Composer Agent.
Плюс, за счет работы напрямую с API LLM-вендоров, они жгут токены довольно активно, и есть истории, когда народ по сотне баксов за день на это умудрялся тратить. В этом плане траты на Cursor предсказуемые и довольно низкие (пока что по крайней мере).
Почему не bolt.new / v0.dev / lovable.dev?
Ну потому что пост от разработчика и в основном для разработчиков :)
И я не люблю последующий потенциальный vendor lock-in, мне нравится всё на своей машине запускать, а потом иметь возможность деплоить куда захочу.
Но! Если у вас таких бзиков нет и вам по большей части нужно сделать именно веб-приложение с простым или отсутствующим бекендом, то советую присмотреться к lovable.dev (и к v0.dev во вторую очередь).
Почему не Windsurf?
Это практически аналог Cursor с упором именно на написание кода в режиме агента, и выпустился он в тот момент, когда у Cursor еще не было Composer Agent.
Но спустя буквально пару недель появился-таки Composer Agent и использование Windsurf потеряло смысл.
Тем не менее, это один из инструментов, к которому стоит присматриваться, т.к. компания, которая его выпустила, обладает большим опытом в плане разработки IDE-тулзов и можно надеяться на то, что Windsurf будет развиваться в правильном направлении.
Почему не Devin?
Потому что $500 в месяц и нацелен сразу на команды. Я про него уже писал, когда он вышел.
Вкратце - это один из вероятных сценариев того, как будет выглядеть будущее командной агентной разработки, но пока что оно не наступило :)
Почему не [yet another tool]...
Потому что столько всего появляется, что не успеваю попробовать :)
Из комментов:
* bolt.dyi - открытая версия bolt.new, можно поставить на свое железо, позволяет работать с большим количеством разных моделей, включая локальные;
* OpenHands (бывший OpenDevin) - открытый аналог Devin, выглядит интересно, в планах попробовать погонять локально.
—
Прошлые посты по связанным темам:
* Разработчики-староверы
* Страхи разработчиков перед ИИ
* Пишем приложение голосом
* Остаточная сложность
* Чёрный ящик
👍12❤4🔥3👏1
Разработка с AI в начале 2025. Выбор LLM (1/3)
Теперь поговорим про выбор LLM-моделей для разработки.
На текущий момент я сам активно пользуюсь такими моделями:
Рабочая лошадка - Claude 3.5 Sonnet (20241022), модель по умолчанию в Cursor у меня, 99% сгенеренного кода пишется именно ею.
Для обсуждения или решения чего-то сложного - ChatGPT o1:
* построение планов - с ней неплохо пообсуждать то, что предстоит делать в рамках проекта/задачи и в итоге получить развернутый и подробный план с брейкдауном;
* архитектура - обсудить верхнеуровневую структуру проекта, контракты между модулями, особенности имплементации, ограничения подходов и т.п.;
* нетривиальные задачи - те, в которых решение не лежит на поверхности и требуется "подумать", а не просто закодить. Как правило, это какие-то алгоритмы или базовая имплементация архитектуры.
В качестве справочника и замены поисковика - ChatGPT 4o, Gemini 2.0 Experimental.
На что обращать внимание при выборе моделей?
Бенчмарки для разработки
К ним можно по-разному относиться, но в целом, если мы говорим про разработку, то я бы больше смотрел на те, которые тестируют не способность модели что-то написать с нуля и за один раз, а способность корректно отредактировать существующий код, т.к. это куда чаще нужно делать в реальной работе.
Есть вот такие бенчмарки, которые это проверяют:
* SWE-bench
* Aider Polyglot
* Aider Refactoring
В конечном счете всегда нужно тестировать модели на ваших задачах.
Если есть время и возможности, то, конечно, составляйте свои бенчмарки или хотя бы чек-листы с любимыми типовыми задачами - так будет куда проще отделить хайп от рабочей необходимости, когда выходит какая-то новая модель :)
Длина контекста
Это, грубо говоря, сколько существующего кода модель может принять во внимание, чтобы делать на его основе выводы для его редактирования или написания нового.
Очень сильно влияет на то, с насколько большими проектами вам получится работать, т.к. если код всего проекта не влезает в контекст LLM - будут проблемы с тем, что модель что-то может нафантазировать и/или написать код, который не будет совместим с не влезшими частями проекта.
Есть техники в тулинге (Cursor, Aider, etc) по тому, чтобы "ужимать" код так, чтобы передавать в контекст его не в сыром виде, а его высокоуровневое представление - куски AST, к примеру, или передавать интерфейсы вместо конкретных реализаций, но это все равно чревато проблемами, т.к. часть информации теряется.
Также длинный контекст модели не всегда бывает "честным", т.к. контекст длиной N требует N^2 GPU RAM для обработки в наивной реализации трансформеров, и его довольно дорого поддерживать, так что применяются разного рода техники для оптимизации расходов памяти, которые могут ощутимо влиять на качество работы модели.
Есть тесты "поиска иголки в стоге сена", которые показывают то, насколько точно модели способны помнить и связывать информацию, находящуюся в разных местах контекста. Так вот на супердлинных контекстах особенно сильно проявляется падение метрик на этих тестах.
А нам нужна точность в разработке :)
#ai #work #development
Теперь поговорим про выбор LLM-моделей для разработки.
На текущий момент я сам активно пользуюсь такими моделями:
Рабочая лошадка - Claude 3.5 Sonnet (20241022), модель по умолчанию в Cursor у меня, 99% сгенеренного кода пишется именно ею.
Для обсуждения или решения чего-то сложного - ChatGPT o1:
* построение планов - с ней неплохо пообсуждать то, что предстоит делать в рамках проекта/задачи и в итоге получить развернутый и подробный план с брейкдауном;
* архитектура - обсудить верхнеуровневую структуру проекта, контракты между модулями, особенности имплементации, ограничения подходов и т.п.;
* нетривиальные задачи - те, в которых решение не лежит на поверхности и требуется "подумать", а не просто закодить. Как правило, это какие-то алгоритмы или базовая имплементация архитектуры.
В качестве справочника и замены поисковика - ChatGPT 4o, Gemini 2.0 Experimental.
На что обращать внимание при выборе моделей?
Бенчмарки для разработки
К ним можно по-разному относиться, но в целом, если мы говорим про разработку, то я бы больше смотрел на те, которые тестируют не способность модели что-то написать с нуля и за один раз, а способность корректно отредактировать существующий код, т.к. это куда чаще нужно делать в реальной работе.
Есть вот такие бенчмарки, которые это проверяют:
* SWE-bench
* Aider Polyglot
* Aider Refactoring
В конечном счете всегда нужно тестировать модели на ваших задачах.
Если есть время и возможности, то, конечно, составляйте свои бенчмарки или хотя бы чек-листы с любимыми типовыми задачами - так будет куда проще отделить хайп от рабочей необходимости, когда выходит какая-то новая модель :)
Длина контекста
Это, грубо говоря, сколько существующего кода модель может принять во внимание, чтобы делать на его основе выводы для его редактирования или написания нового.
Очень сильно влияет на то, с насколько большими проектами вам получится работать, т.к. если код всего проекта не влезает в контекст LLM - будут проблемы с тем, что модель что-то может нафантазировать и/или написать код, который не будет совместим с не влезшими частями проекта.
Есть техники в тулинге (Cursor, Aider, etc) по тому, чтобы "ужимать" код так, чтобы передавать в контекст его не в сыром виде, а его высокоуровневое представление - куски AST, к примеру, или передавать интерфейсы вместо конкретных реализаций, но это все равно чревато проблемами, т.к. часть информации теряется.
Также длинный контекст модели не всегда бывает "честным", т.к. контекст длиной N требует N^2 GPU RAM для обработки в наивной реализации трансформеров, и его довольно дорого поддерживать, так что применяются разного рода техники для оптимизации расходов памяти, которые могут ощутимо влиять на качество работы модели.
Есть тесты "поиска иголки в стоге сена", которые показывают то, насколько точно модели способны помнить и связывать информацию, находящуюся в разных местах контекста. Так вот на супердлинных контекстах особенно сильно проявляется падение метрик на этих тестах.
А нам нужна точность в разработке :)
#ai #work #development
👍6❤4🔥3👏2
Разработка с AI в начале 2025. Выбор LLM (2/3)
Ризонинг
Способность модели рассуждать, делать выводы, устанавливать логические связи между фактами и генерировать ответы, основанные не только на запоминании информации, но и на ее анализе и интерпретации.
В разработке определенно нужны модели с хорошим ризонингом, и чем сложнее и нетривиальнее задачи, тем более важным становится этот фактор.
Появившиеся не так давно "размышляющие" модели навроде ChatGPT o1 (на подходе передовая o3) или Qwen QwQ заточены именно на построение цепочки рассуждений и особенно выделяются способностями решать задачи на ризонинг.
Эта способность не нова, такое поведение можно было и раньше получить от "обычных" моделей, попросив их составлять план действий, думать по шагам и т.п.
Собственно, можно видеть, как тот же Cursor Composer так и делает, когда он просит модель составить план, а потом по этому плану двигается, редактируя код и запуская команды.
Сейчас есть 2 минуса "думающих" моделей:
* дороговизна, т.к. построение и прохождение по цепочке рассуждений вычислительно дорогой процесс;
* скорость работы, т.к. нужно время "подумать" :)
Так что ту же о1 я использую нечасто, да и для большинства стандартных задач это оверкилл, Sonnet'а вполне хватает.
Использование инструментов
Это способность модели принимать в запросе описание набора инструментов, которые она может использовать и умение эти инструменты применять в ответе.
Выглядит в промпте это так, что модели предоставляются контракты для вызова инструментов и ставится задача, которую она потенциально может решить с помощью вызова этих инструментов.
В своем ответе она описывает, какой инструмент и с какими параметрами нужно запустить, мы на своей стороне его запускаем, а в ответ предоставляем ей и/или пользователю результат выполнения.
Эффективное использование инструментов требует следующих способностей модели:
* хорошей общей способности следовать инструкциям;
* умения планировать свои действия;
* точного понимания структуры входящего запроса (как правило, json);
* генерации структурного вывода заданного формата (structured outputs, как правило, тоже в виде json);
* иногда - просить уточнения требований.
За счет всего этого есть возможность организовать цикл с обратной связью и модель будет в автономном режиме (т.е. в режиме агента) решать какую-то задачу.
Простой пример: модель может написать код, запустить тесты, отловить ошибки, поправить код, запустить тесты, и так до тех пор, пока задача не будет решена.
Стоит подчеркнуть, что, конечно, все эти действия модель совершает не сама - их совершает тулинг, выстроенный вокруг модели (такой, как Cursor Composer Agent, к примеру), а модель тут лишь генерирует инструкции.
Так вот, не все модели обладают вышеперечисленными способностями, и в Cursor Composer Agent в том числе из-за этого далеко не все модели поддерживаются.
Вот, к примеру, та же Gemini 2.0 Flash, несмотря на общие неплохие способности к программированию, не всегда следует инструкциям по оформлению своего вывода, чем ломает даже обычный Cursor Composer и приходится (какое средневековье!) руками копировать куски кода из чата в файл.
#ai #work #development
Ризонинг
Способность модели рассуждать, делать выводы, устанавливать логические связи между фактами и генерировать ответы, основанные не только на запоминании информации, но и на ее анализе и интерпретации.
В разработке определенно нужны модели с хорошим ризонингом, и чем сложнее и нетривиальнее задачи, тем более важным становится этот фактор.
Появившиеся не так давно "размышляющие" модели навроде ChatGPT o1 (на подходе передовая o3) или Qwen QwQ заточены именно на построение цепочки рассуждений и особенно выделяются способностями решать задачи на ризонинг.
Эта способность не нова, такое поведение можно было и раньше получить от "обычных" моделей, попросив их составлять план действий, думать по шагам и т.п.
Собственно, можно видеть, как тот же Cursor Composer так и делает, когда он просит модель составить план, а потом по этому плану двигается, редактируя код и запуская команды.
Сейчас есть 2 минуса "думающих" моделей:
* дороговизна, т.к. построение и прохождение по цепочке рассуждений вычислительно дорогой процесс;
* скорость работы, т.к. нужно время "подумать" :)
Так что ту же о1 я использую нечасто, да и для большинства стандартных задач это оверкилл, Sonnet'а вполне хватает.
Использование инструментов
Это способность модели принимать в запросе описание набора инструментов, которые она может использовать и умение эти инструменты применять в ответе.
Выглядит в промпте это так, что модели предоставляются контракты для вызова инструментов и ставится задача, которую она потенциально может решить с помощью вызова этих инструментов.
В своем ответе она описывает, какой инструмент и с какими параметрами нужно запустить, мы на своей стороне его запускаем, а в ответ предоставляем ей и/или пользователю результат выполнения.
Эффективное использование инструментов требует следующих способностей модели:
* хорошей общей способности следовать инструкциям;
* умения планировать свои действия;
* точного понимания структуры входящего запроса (как правило, json);
* генерации структурного вывода заданного формата (structured outputs, как правило, тоже в виде json);
* иногда - просить уточнения требований.
За счет всего этого есть возможность организовать цикл с обратной связью и модель будет в автономном режиме (т.е. в режиме агента) решать какую-то задачу.
Простой пример: модель может написать код, запустить тесты, отловить ошибки, поправить код, запустить тесты, и так до тех пор, пока задача не будет решена.
Стоит подчеркнуть, что, конечно, все эти действия модель совершает не сама - их совершает тулинг, выстроенный вокруг модели (такой, как Cursor Composer Agent, к примеру), а модель тут лишь генерирует инструкции.
Так вот, не все модели обладают вышеперечисленными способностями, и в Cursor Composer Agent в том числе из-за этого далеко не все модели поддерживаются.
Вот, к примеру, та же Gemini 2.0 Flash, несмотря на общие неплохие способности к программированию, не всегда следует инструкциям по оформлению своего вывода, чем ломает даже обычный Cursor Composer и приходится (какое средневековье!) руками копировать куски кода из чата в файл.
#ai #work #development
🔥11❤3👏3❤🔥1