Про ценообразование.
Тут недавно у перспективного 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
😁9🔥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
Разработка с AI в начале 2025. Выбор LLM (3/3)
Локальность
Это когда вы скачиваете веса модели (если они доступны) и запускаете её локально, на своем железе.
Так вот, по всей видимости, на текущий момент это не особо оправданно, если только у вас не какой-то особенный use case, и вот почему:
* модели становятся огромными - к примеру, вышедший на днях DeepSeek v3 требует 671GB GPU RAM для работы (самая продвинутая "домашняя" видеокарта на текущий момент имеет объем видеопамяти 24GB);
* онлайн-инференс становится всё дешевле - тот же DeepSeek v3 стоит 28 центов за 1м сгенерированных токенов;
* серверные GPU становятся дороже, но при этом скорость их работы возрастает в разы с каждым новым поколением.
Такими темпами даже электричество для работы, скажем, домашней RTX3090 становится дороже, чем использование онлайн-моделей, не говоря уж о цене сборки системы для запуска современных моделей на ее основе :)
Впрочем, тут есть и другой тренд: постепенное улучшение локальных моделей - они становятся умнее и быстрее, даже на тех размерах, которые можно запустить на домашнем железе.
В какой-то момент локальные модели станут достаточно хороши, чтобы тягаться в некоторых задачах с современными большими коммерческими моделями навроде ChatGPT 4o или Claude 3.5 Sonnet, однако:
* до этого может пройти год-другой - это ооочень долго при современной скорости развития AI;
* к тому времени облачные модели могут достичь какой-то фантастической производительности и качества;
* скорее всего контекст локальных моделей так и останется коротким, т.к. мы помним из прошлого поста, что контекст длиной N требует N^2 GPU RAM.
С локальными моделями, безусловно, интересно возиться, если у вас есть страсть к администрированию и некоторая гиковость (каюсь, сам грешен), но на текущий момент в большинстве случаев это лишено практического смысла (для целей написания кода, уж точно).
К чему присматриваться
DeepSeek V3 - очень дешевая и умная модель, которая вот практически только-только вышла и по некоторым тестам превосходит Claude 3.5 Sonnet.
На бумаге единственный её существенный минус - контекст в 64k токенов против 200k у Claude 3.5 Sonnet, так что нужно будет посмотреть, как она себя будет вести на рабочих задачах.
Однозначно буду пробовать :)
Семейство моделей-ризонеров - ChatGPT o3, Qwen QwQ.
Пока что не вышедшая в паблик ChatGPT o3 по предварительным тестам - лучшая модель по ризонингу, так что будет интересно проверить её в работе над сложными задачами.
Плюс, стоит надеяться на то, что стоимость таких моделей будет падать, а скорость инференса - расти, так что они видятся перспективными для написания кода в будущем.
#ai #work #development
Локальность
Это когда вы скачиваете веса модели (если они доступны) и запускаете её локально, на своем железе.
Так вот, по всей видимости, на текущий момент это не особо оправданно, если только у вас не какой-то особенный use case, и вот почему:
* модели становятся огромными - к примеру, вышедший на днях DeepSeek v3 требует 671GB GPU RAM для работы (самая продвинутая "домашняя" видеокарта на текущий момент имеет объем видеопамяти 24GB);
* онлайн-инференс становится всё дешевле - тот же DeepSeek v3 стоит 28 центов за 1м сгенерированных токенов;
* серверные GPU становятся дороже, но при этом скорость их работы возрастает в разы с каждым новым поколением.
Такими темпами даже электричество для работы, скажем, домашней RTX3090 становится дороже, чем использование онлайн-моделей, не говоря уж о цене сборки системы для запуска современных моделей на ее основе :)
Впрочем, тут есть и другой тренд: постепенное улучшение локальных моделей - они становятся умнее и быстрее, даже на тех размерах, которые можно запустить на домашнем железе.
В какой-то момент локальные модели станут достаточно хороши, чтобы тягаться в некоторых задачах с современными большими коммерческими моделями навроде ChatGPT 4o или Claude 3.5 Sonnet, однако:
* до этого может пройти год-другой - это ооочень долго при современной скорости развития AI;
* к тому времени облачные модели могут достичь какой-то фантастической производительности и качества;
* скорее всего контекст локальных моделей так и останется коротким, т.к. мы помним из прошлого поста, что контекст длиной N требует N^2 GPU RAM.
С локальными моделями, безусловно, интересно возиться, если у вас есть страсть к администрированию и некоторая гиковость (каюсь, сам грешен), но на текущий момент в большинстве случаев это лишено практического смысла (для целей написания кода, уж точно).
К чему присматриваться
DeepSeek V3 - очень дешевая и умная модель, которая вот практически только-только вышла и по некоторым тестам превосходит Claude 3.5 Sonnet.
На бумаге единственный её существенный минус - контекст в 64k токенов против 200k у Claude 3.5 Sonnet, так что нужно будет посмотреть, как она себя будет вести на рабочих задачах.
Однозначно буду пробовать :)
Семейство моделей-ризонеров - ChatGPT o3, Qwen QwQ.
Пока что не вышедшая в паблик ChatGPT o3 по предварительным тестам - лучшая модель по ризонингу, так что будет интересно проверить её в работе над сложными задачами.
Плюс, стоит надеяться на то, что стоимость таких моделей будет падать, а скорость инференса - расти, так что они видятся перспективными для написания кода в будущем.
#ai #work #development
🔥7❤4👍3
Разработка с AI в начале 2025. Ограничения и решения (1/2)
Нет инструментов без своих минусов, так что в этой, финальной части, обсудим текущие проблемы и ограничения, которые чаще всего встречаются в AI-разработке, а также способы их обойти или решить.
Ограниченность длины контекста
Проявляется в том, что не весь ваш код и документация могут быть "осознаны" и учтены, так что в ответ модель запросто может начать фантазировать о тех частях проекта, которые она "не видит", забывать тот код, который сама же написала и терять логические связи между разными участками кода.
Последнее особенно ярко заметно на очень длинных контекстах, которые не являются "честными" (см. прошлый пост с подробностями).
Что делать?
* не пытаться засунуть в контекст сразу весь проект, если размер контекста этого не позволяет;
* дробить проект на модули и разрабатывать их по отдельности - это в целом полезная практика;
* иметь четко прописанные контракты между модулями (Swagger/OpenAPI, JSON Schema, интерфейсы в коде и т.п.), которые нужно класть в контекст; а также полезно иметь интеграционные тесты.
Слишком длинные чаты
Если вы пишете код в том же Cursor (и даже если почему-то до сих пор в веб-интерфейсе ChatGPT), вы наверняка сталкивались с тем, что спустя некоторое время модель начинает путаться в показаниях и отвечать все хуже и хуже, а иногда даже удалять нужный код.
Это, во-первых, может быть связано с тем, что весь ваш чат перестал влезать в контекст, а во-вторых, если вы переиспользуете один и тот же чат для разных задач, то происходит замусоривание контекста и модель может начать пытаться связать между собой какие-то не относящиеся друг к другу факты, попавшие в этот контекст.
Что делать?
* по-хорошему, один чат в Cursor Chat - один мелкий фикс или серия фиксов связанного функционала;
* в Cursor Composer - один чат на фичу / большое изменение;
* если чат даже по одной фиче стал слишком большим - просите модель описать те изменения, которые были сделаны в рамках этого чата, идите с этим описанием в новый чат и продолжайте работу там.
Устаревший код
Нередко бывает, что для какой-то либы LLM предлагает поставить её старую версию и/или пишет код для старой версии.
Тут дело в том, что у каждой LLM есть knowledge cutoff date - та дата, которой ограничен собранный для нее датасет.
Ну т.е. для тренировки условной ChatGPT 4o данные могли собрать из Интернета еще года полтора назад, потом полгода ее на этих данных учили, выпустили, а мы до сих пор ей пользуемся. Добросить в неё новые знания - вычислительно и финансово весьма накладно, так что модели не так часто обновляются.
Что делать?
* если документация не очень большая (помним про размер контекста), можно прям целиком её копипастнуть в чат с LLM или, что удобнее, дать ссылку на страницу документации в том же Cursor Composer - он сам ее скачает, распарсит и положит в контекст для модели;
* попробовать использовать символ @Web в Cursor - он запускает поиск релевантной вашему сообщению инфы в сети и потом включает результаты поиска в текущий контекст;
* переключиться на модель поновее - как правило, у недавно вышедших моделей cutoff date позднее и знания более актуальные;
* не использовать самые новые версии библиотек :) Не, ну кроме шуток - это нередко себя оправдывает.
К примеру, Angular и в прошлом году уже был достаточен для подавляющего большинства проектов, и большого профита от его свежего релиза скорее всего не получить, а вот бороться с LLM придется.
Конечно, нужно выбирать те версии, которые не совсем заброшены и хотя бы всё ещё получают обновления безопасности.
Языки программирования тоже лучше выбирать как можно более массовые и стабильные, по тем же причинам.
В особо тяжелых случаях модель вообще может не знать конкретного языка / фреймворка или иметь очень мало по нему данных для того, чтобы писать рабочий код.
В этом случае придётся либо все-таки писать код самому, либо креативно сочетать подходы выше.
#ai #work #development
Нет инструментов без своих минусов, так что в этой, финальной части, обсудим текущие проблемы и ограничения, которые чаще всего встречаются в AI-разработке, а также способы их обойти или решить.
Ограниченность длины контекста
Проявляется в том, что не весь ваш код и документация могут быть "осознаны" и учтены, так что в ответ модель запросто может начать фантазировать о тех частях проекта, которые она "не видит", забывать тот код, который сама же написала и терять логические связи между разными участками кода.
Последнее особенно ярко заметно на очень длинных контекстах, которые не являются "честными" (см. прошлый пост с подробностями).
Что делать?
* не пытаться засунуть в контекст сразу весь проект, если размер контекста этого не позволяет;
* дробить проект на модули и разрабатывать их по отдельности - это в целом полезная практика;
* иметь четко прописанные контракты между модулями (Swagger/OpenAPI, JSON Schema, интерфейсы в коде и т.п.), которые нужно класть в контекст; а также полезно иметь интеграционные тесты.
Слишком длинные чаты
Если вы пишете код в том же Cursor (и даже если почему-то до сих пор в веб-интерфейсе ChatGPT), вы наверняка сталкивались с тем, что спустя некоторое время модель начинает путаться в показаниях и отвечать все хуже и хуже, а иногда даже удалять нужный код.
Это, во-первых, может быть связано с тем, что весь ваш чат перестал влезать в контекст, а во-вторых, если вы переиспользуете один и тот же чат для разных задач, то происходит замусоривание контекста и модель может начать пытаться связать между собой какие-то не относящиеся друг к другу факты, попавшие в этот контекст.
Что делать?
* по-хорошему, один чат в Cursor Chat - один мелкий фикс или серия фиксов связанного функционала;
* в Cursor Composer - один чат на фичу / большое изменение;
* если чат даже по одной фиче стал слишком большим - просите модель описать те изменения, которые были сделаны в рамках этого чата, идите с этим описанием в новый чат и продолжайте работу там.
Устаревший код
Нередко бывает, что для какой-то либы LLM предлагает поставить её старую версию и/или пишет код для старой версии.
Тут дело в том, что у каждой LLM есть knowledge cutoff date - та дата, которой ограничен собранный для нее датасет.
Ну т.е. для тренировки условной ChatGPT 4o данные могли собрать из Интернета еще года полтора назад, потом полгода ее на этих данных учили, выпустили, а мы до сих пор ей пользуемся. Добросить в неё новые знания - вычислительно и финансово весьма накладно, так что модели не так часто обновляются.
Что делать?
* если документация не очень большая (помним про размер контекста), можно прям целиком её копипастнуть в чат с LLM или, что удобнее, дать ссылку на страницу документации в том же Cursor Composer - он сам ее скачает, распарсит и положит в контекст для модели;
* попробовать использовать символ @Web в Cursor - он запускает поиск релевантной вашему сообщению инфы в сети и потом включает результаты поиска в текущий контекст;
* переключиться на модель поновее - как правило, у недавно вышедших моделей cutoff date позднее и знания более актуальные;
* не использовать самые новые версии библиотек :) Не, ну кроме шуток - это нередко себя оправдывает.
К примеру, Angular и в прошлом году уже был достаточен для подавляющего большинства проектов, и большого профита от его свежего релиза скорее всего не получить, а вот бороться с LLM придется.
Конечно, нужно выбирать те версии, которые не совсем заброшены и хотя бы всё ещё получают обновления безопасности.
Языки программирования тоже лучше выбирать как можно более массовые и стабильные, по тем же причинам.
В особо тяжелых случаях модель вообще может не знать конкретного языка / фреймворка или иметь очень мало по нему данных для того, чтобы писать рабочий код.
В этом случае придётся либо все-таки писать код самому, либо креативно сочетать подходы выше.
#ai #work #development
🔥8👍6🤔2❤1
Разработка с AI в начале 2025. Ограничения и решения (2/2)
Вероятностность
Это вообще общее свойство работы с текущими ИИ - что сработало 9 раз, на 10й может сломаться, и это норма, нужно попробовать еще раз (возможно, переформулировав запрос). Благо, что тот же Cursor Composer делает снапшоты и можно быстро откатить его изменения, ну и в крайнем случае гитом ведь все же пользуются, верно? :)
Также стоит самому проверять то, что вам выдает ИИ, причем для того, чтобы понять, всё ли в порядке, даже не всегда нужно читать код - тот же Cursor довольно подробно описывает сделанные изменения человеческим языком, и этого часто хватает, чтобы понять, всё ли идет как вы планировали.
Не та стилистика кода
По умолчанию современные модели будут пытаться подстраиваться под стиль кода в вашем проекте (с переменным успехом), но если проект новый - будет выбран какой-то из стилей, с которыми модель чаще всего сталкивалась при обучении.
Что делать?
Не стесняться сказать модели, какой стиль нужно использовать, если его можно кратко описать в чате.
Если кратко на ходу не получится описать - можно сделать отдельный файл, расписать там правила для стиля подробно, и каждый раз этот файл класть в контекст, чтобы модель про него знала и учитывала при написании кода.
Для этого, кстати, хорошо подходит файл .cursorrules в Cursor, который сам автоматически включается в контекст.
ИИ не понимает проект
Современные нейронки довольно неплохо ухватывают суть кода, но если мы говорим о каком-то отдельном модуле или нетривиальном проекте, то общая картина может потеряться.
Что делать?
Точно так же, как и со стилем кода, в контекст модели можно класть документацию по проекту, причем желательно в простом текстовом формате навроде Markdown.
А если у вас есть публичная ссылка на документацию - можно её вставить в чат.
Есть более продвинутые подходы - когда по вашему запросу перед тем, как его отправить LLM, сторонняя система его сначала использует для поиска релевантной документации в базе знаний проекта, выделяет нужные куски оттуда и готовит их для включения в контекст (подходы RAG, Knowledge Graph, etc), но вот пока что этот тулинг существует отдельно от AI-редакторов, что делает этот вариант не очень удобным, но осуществимым.
Ждём такой встроенной фичи, это явно упростит жизнь на сложных и больших проектах.
У меня реально большой проект
Ключевые слова тут такие: планирование, декомпозиция, модульность, чёткие контракты, документация - т.е. всё то же самое, что нужно и людям, работающим на большом проекте.
Из этого всего проистекает набор частично оформившихся и пока что меняющихся на ходу практик, которые упрощают работу над большими проектами, но это уже тема отдельного поста.
Заранее скажу, что тут не стоит надеяться на чудо - с наскоку фичу в большом проекте или какой-то широкий рефакторинг сделать не получится, нужно быть аккуратным в том, как вы распорядитесь ограниченным контекстом модели.
Моя модель меня не слушается :)
Нууу, с ними такое бывает :) Особенно когда контекст кончается или в нем накопилась куча нерелеватных текущей задаче данных.
Впрочем, это в целом беда некоторых моделей попроще - тот же DeepSeek, к примеру, менее управляем, чем Sonnet.
Что делать?
* давать модели более чёткие, формальные инструкции, особенно для нетривиальных задач;
* давать больше сведений о том, для чего и почему что-то делается, с чем связан функционал;
* вовремя избавляться от старого контекста, переходя в новый чат.
#ai #work #development
Вероятностность
Это вообще общее свойство работы с текущими ИИ - что сработало 9 раз, на 10й может сломаться, и это норма, нужно попробовать еще раз (возможно, переформулировав запрос). Благо, что тот же Cursor Composer делает снапшоты и можно быстро откатить его изменения, ну и в крайнем случае гитом ведь все же пользуются, верно? :)
Также стоит самому проверять то, что вам выдает ИИ, причем для того, чтобы понять, всё ли в порядке, даже не всегда нужно читать код - тот же Cursor довольно подробно описывает сделанные изменения человеческим языком, и этого часто хватает, чтобы понять, всё ли идет как вы планировали.
Не та стилистика кода
По умолчанию современные модели будут пытаться подстраиваться под стиль кода в вашем проекте (с переменным успехом), но если проект новый - будет выбран какой-то из стилей, с которыми модель чаще всего сталкивалась при обучении.
Что делать?
Не стесняться сказать модели, какой стиль нужно использовать, если его можно кратко описать в чате.
Если кратко на ходу не получится описать - можно сделать отдельный файл, расписать там правила для стиля подробно, и каждый раз этот файл класть в контекст, чтобы модель про него знала и учитывала при написании кода.
Для этого, кстати, хорошо подходит файл .cursorrules в Cursor, который сам автоматически включается в контекст.
ИИ не понимает проект
Современные нейронки довольно неплохо ухватывают суть кода, но если мы говорим о каком-то отдельном модуле или нетривиальном проекте, то общая картина может потеряться.
Что делать?
Точно так же, как и со стилем кода, в контекст модели можно класть документацию по проекту, причем желательно в простом текстовом формате навроде Markdown.
А если у вас есть публичная ссылка на документацию - можно её вставить в чат.
Есть более продвинутые подходы - когда по вашему запросу перед тем, как его отправить LLM, сторонняя система его сначала использует для поиска релевантной документации в базе знаний проекта, выделяет нужные куски оттуда и готовит их для включения в контекст (подходы RAG, Knowledge Graph, etc), но вот пока что этот тулинг существует отдельно от AI-редакторов, что делает этот вариант не очень удобным, но осуществимым.
Ждём такой встроенной фичи, это явно упростит жизнь на сложных и больших проектах.
У меня реально большой проект
Ключевые слова тут такие: планирование, декомпозиция, модульность, чёткие контракты, документация - т.е. всё то же самое, что нужно и людям, работающим на большом проекте.
Из этого всего проистекает набор частично оформившихся и пока что меняющихся на ходу практик, которые упрощают работу над большими проектами, но это уже тема отдельного поста.
Заранее скажу, что тут не стоит надеяться на чудо - с наскоку фичу в большом проекте или какой-то широкий рефакторинг сделать не получится, нужно быть аккуратным в том, как вы распорядитесь ограниченным контекстом модели.
Моя модель меня не слушается :)
Нууу, с ними такое бывает :) Особенно когда контекст кончается или в нем накопилась куча нерелеватных текущей задаче данных.
Впрочем, это в целом беда некоторых моделей попроще - тот же DeepSeek, к примеру, менее управляем, чем Sonnet.
Что делать?
* давать модели более чёткие, формальные инструкции, особенно для нетривиальных задач;
* давать больше сведений о том, для чего и почему что-то делается, с чем связан функционал;
* вовремя избавляться от старого контекста, переходя в новый чат.
#ai #work #development
🔥11👍7🤔2❤1
Разработка с AI в начале 2025, cерия постов:
—
1️⃣ Выбор IDE: раз, два.
2️⃣ Выбор LLM: раз, два, три.
3️⃣ Ограничения и решения: раз, два.
—
Это сбалансированная база для разработчиков, с неё можно стартовать для того, чтобы иметь общее понимание и набор инструментов для работы с AI для написания кода.
Ну а дальше только практика, наработка собственного опыта и выстраивание удобного workflow.
AI для разработки - ультимативная штука, расширяющая возможности программистов, так что, надеюсь, эта серия постов окажется полезной для знакомства с текущим состоянием дел в этой области :)
Несколько лайтовых записей для подводки:
* Пишем приложение голосом
* Разработчики-староверы
* Страхи разработчиков перед ИИ
* Остаточная сложность
* Чёрный ящик
—
Всех с наступающим и отличных праздников! 🎄
#ai #work #development
—
1️⃣ Выбор IDE: раз, два.
2️⃣ Выбор LLM: раз, два, три.
3️⃣ Ограничения и решения: раз, два.
—
Это сбалансированная база для разработчиков, с неё можно стартовать для того, чтобы иметь общее понимание и набор инструментов для работы с AI для написания кода.
Ну а дальше только практика, наработка собственного опыта и выстраивание удобного workflow.
AI для разработки - ультимативная штука, расширяющая возможности программистов, так что, надеюсь, эта серия постов окажется полезной для знакомства с текущим состоянием дел в этой области :)
Несколько лайтовых записей для подводки:
* Пишем приложение голосом
* Разработчики-староверы
* Страхи разработчиков перед ИИ
* Остаточная сложность
* Чёрный ящик
—
Всех с наступающим и отличных праздников! 🎄
#ai #work #development
🔥11🎄5🎉4