Как одним промптом решить задачу, которую AI coding агенты будут пилить 30-90 минут?
Вот примеры промптов, которые решают упражнение из предыдущего поста, где надо было написать утилиту для удобного выбора и "склеивания" файлов перед отправкой в OpenAI API.
Напомню, что когда я дал эту задачу ребятам из экспериментальной группы по AI Coding, они потратили на нее 30-120 минут используя всякие новомодные Coding Agents и IDEшки. А потом, когда я объяснил, что задача решается за 5-15 минут одним запросом к обычному чату, уже подошли к задаче осознаннее.
Мой вариант - 73 tokens / 322 chars:
Участник экспериментальной группы - 24 tokens and 99 characters (промпт пока не прислал)
@xsl77 - 27 tokens / 132 chars:
А теперь, самое важное. Задачка была просто для тренировки, чтобы прочувствовать пределы и возможности LLM на практике. Чтобы понять, насколько легко сложные инструменты могут создать иллюзию продуктивной работы (по паре часов возни с Windsurf / Cursor.sh у участников), когда задача решается одним промптом в Claude 3.7 Sonnet (или аналоге).
На практике не имеет никакого смысла каждый раз упражняться в знании английского и паковать требования в крохотный малопонятный текст. Достаточно просто осознанно подбирать инструменты под задачу.
Ваш, @llm_under_hood 🤗
PS: А самое забавное, что в моем промпте я забыл уточнить, что приложение должно быть на web. Поэтому Claude 3.7 с первой попытки сделало работающее десктопное приложение на electron. Скриншот в комментариях.
Вот примеры промптов, которые решают упражнение из предыдущего поста, где надо было написать утилиту для удобного выбора и "склеивания" файлов перед отправкой в OpenAI API.
Напомню, что когда я дал эту задачу ребятам из экспериментальной группы по AI Coding, они потратили на нее 30-120 минут используя всякие новомодные Coding Agents и IDEшки. А потом, когда я объяснил, что задача решается за 5-15 минут одним запросом к обычному чату, уже подошли к задаче осознаннее.
Мой вариант - 73 tokens / 322 chars:
node.js application:
- recursively list all files from a directory, passed as CLI argument
- let user add/remove files to include in LLM prompt
- submits user prompt plus file contents prefixed by filenames to gpt-4o
- displays response
UI: left pane with file tree, right pane: prompt, selected files, “Submit”, response
Участник экспериментальной группы - 24 tokens and 99 characters (промпт пока не прислал)
@xsl77 - 27 tokens / 132 chars:
Nodejs web app showing dir (command line param) files tree users select deselect, OpenAI response for prompt input and file contents
А теперь, самое важное. Задачка была просто для тренировки, чтобы прочувствовать пределы и возможности LLM на практике. Чтобы понять, насколько легко сложные инструменты могут создать иллюзию продуктивной работы (по паре часов возни с Windsurf / Cursor.sh у участников), когда задача решается одним промптом в Claude 3.7 Sonnet (или аналоге).
На практике не имеет никакого смысла каждый раз упражняться в знании английского и паковать требования в крохотный малопонятный текст. Достаточно просто осознанно подбирать инструменты под задачу.
Ваш, @llm_under_hood 🤗
PS: А самое забавное, что в моем промпте я забыл уточнить, что приложение должно быть на web. Поэтому Claude 3.7 с первой попытки сделало работающее десктопное приложение на electron. Скриншот в комментариях.
❤75🔥25👍19🤣5
Сегодня каналу LLM под капотом исполняется два года!
За это время мы сделали много всего интересного.
Разобрали кучу кейсов, научились применять SO CoT, запустили один курс, провели дюжину вебинаров и два крутых раунда Enterprise RAG Challenge (ERC).
Во втором раунде приняло участие 350 команд со всего мира и один директор от AI из Intel. В IBM и паре других компаний до сих пор обсуждают результаты ERC и хвалят материалы. Их даже отметил LangChain (195k подписчиков), пару дней назад опубликовав ссылку на GitHub-решение Ильи по ERCr2.
Благодаря нашему комьюнити кто-то нашёл новую работу и запустил интересные проекты, кто-то познакомился с талантливыми сотрудниками и единомышленниками, а в описаниях вакансий стало появляться умение применять Structured Outputs.
Огромное вам спасибо за поддержку, ваши вопросы, советы и живые обсуждения. Именно вы делаете канал особенным и полезным для многих!
Расскажите, что лично вам запомнилось или чем был полезен канал за эти два года!
Ваш, @llm_under_hood 🥳
За это время мы сделали много всего интересного.
Разобрали кучу кейсов, научились применять SO CoT, запустили один курс, провели дюжину вебинаров и два крутых раунда Enterprise RAG Challenge (ERC).
Во втором раунде приняло участие 350 команд со всего мира и один директор от AI из Intel. В IBM и паре других компаний до сих пор обсуждают результаты ERC и хвалят материалы. Их даже отметил LangChain (195k подписчиков), пару дней назад опубликовав ссылку на GitHub-решение Ильи по ERCr2.
Благодаря нашему комьюнити кто-то нашёл новую работу и запустил интересные проекты, кто-то познакомился с талантливыми сотрудниками и единомышленниками, а в описаниях вакансий стало появляться умение применять Structured Outputs.
Огромное вам спасибо за поддержку, ваши вопросы, советы и живые обсуждения. Именно вы делаете канал особенным и полезным для многих!
Расскажите, что лично вам запомнилось или чем был полезен канал за эти два года!
Ваш, @llm_under_hood 🥳
🔥185🎉74❤34👍16👏5
Третье упражнение AI Coding эксперимента - добавим красоты в презентации и посты
- первое упражнение / вариант решения
- второе упражнение / варианты решения
Это упражнение вдохновлено промптом, который Валерий опубликовал у себя в канале.
Задача - написать промпт, который будет по запросу рисовать красивые слайды в едином стиле компании или бренда. Эту красоту потом можно вставлять в посты, сообщения или презентации.
Стиль вы выбираете сами. Можно попросить переиспользовать дизайн OpenAI / Google / Apple или скормить приятный вам сайт/ресурс.
Получившийся промпт нужно вставить в Claude Project, ChatGPT Project или любой другой инструмент, который позволяет удобно переиспользовать шаблон промпта и отображать результат на экране.
Тут не стоит задачи сделать красивую картинку с первого раза. Задача - попробовать с нуля “собрать” простейший инструмент со своим стилем, который за пару минут может сгенерировать симпатичную иллюстрацию к вашему рассказу или посту. А рецепт создания слайдов потом можно будет неспеша “подкрутить” под свой стиль.
Потом нужно этим инструментом сгенерировать пару слайдов и прислать их в комментарии. Я туда выложу пару слайдов, которые сгенерировал на основе стиля TAT.
Ваш, @llm_under_hood 🤗
- первое упражнение / вариант решения
- второе упражнение / варианты решения
Это упражнение вдохновлено промптом, который Валерий опубликовал у себя в канале.
Задача - написать промпт, который будет по запросу рисовать красивые слайды в едином стиле компании или бренда. Эту красоту потом можно вставлять в посты, сообщения или презентации.
Стиль вы выбираете сами. Можно попросить переиспользовать дизайн OpenAI / Google / Apple или скормить приятный вам сайт/ресурс.
Получившийся промпт нужно вставить в Claude Project, ChatGPT Project или любой другой инструмент, который позволяет удобно переиспользовать шаблон промпта и отображать результат на экране.
Тут не стоит задачи сделать красивую картинку с первого раза. Задача - попробовать с нуля “собрать” простейший инструмент со своим стилем, который за пару минут может сгенерировать симпатичную иллюстрацию к вашему рассказу или посту. А рецепт создания слайдов потом можно будет неспеша “подкрутить” под свой стиль.
Потом нужно этим инструментом сгенерировать пару слайдов и прислать их в комментарии. Я туда выложу пару слайдов, которые сгенерировал на основе стиля TAT.
Ваш, @llm_under_hood 🤗
🔥26👍16❤10
Забавный кейс про 700000 строчек дремучего кода
Я давно не рассказывал про новые кейсы, т.к. проекты в основном встречаются повторяющиеся. В основном это data extraction - извлечение данных из PDF data sheets, purchase orders (с последующей сверкой или интеграцией). Иногда встречается какой-нибудь интересный поиск по документам.
Но вот появился принципиально новый интересный кейс применения LLM. На самом деле, он старый, но я лично с подобными масштабами не сталкивался.
Итак, есть одна компания, которой больше 100 лет. У нее есть своя самописная ERP система. Это система будет помоложе компании, и она написана на языке разработки бизнес-приложений со времен мейнфреймов, которому уже более 40 лет (для сравнения, 1C - моложе). БД в этой среде своя - проприетарная, интерфейс - терминал 80x25. Кода там - 700000 строчек, преимущественно CRUD и бизнес-логика рядом.
Это не IBM AS/400 с DB2, но что-то очень близкое по духу. Но и тут нужно платить дорогие лицензии, а разработчиков найти практически невозможно.
Компания хочет обновить код на что-то посовременнее. Не ради современности, а для того, чтобы были живые разработчики, которых можно нанять. Заодно клиент хочет еще и интерфейс сделать современным, но так, чтобы все горячие клавиши и последовательности символов работали, как раньше.
Соответственно, возник вопрос в системной оценке проекта - можно ли здесь как-нибудь ускорить процесс переписывания при помощи LLM, как вообще подходить к проекту, какие риски могут быть, как их лучше “вскрыть” пораньше?
И если начать копать, то получается интересная картина. В этой формулировке проекта компания смешала две разные задачи в одну кучу. И лучше бы их разделить, чтобы не умножать риски сверх нужды (я видел проекты, которые на этом погорели).
Первая задача - модернизация кода и перенос ERP системы с дремучего языка на JVM, без изменения терминального интерфейса. Функционал остается тот же самый, просто код читаем и не нужно платить адские суммы в год за лицензии.
Вторая задача - берем портированный и вычищенный код и уже свежими силами переписываем терминальный интерфейс на более “красивый” со всяким React/Desktop итп.
Так вот, в такой формулировке меньше всего рисков в первой части, т.к. можно использовать современные модели для ускорения анализа и переноса (Gemini Pro 2.5 очень удачно вышел). Но, самое главное - scope проекта: чтобы все работало точно так же, как и раньше, но только в браузере или в современном терминале.
А у терминальных приложений есть одна приятная черта - их достаточно просто протестировать на работу “точно так же”. Сажаем эксперта за оригинальное приложение, делаем snapshot БД и просим его реализовать какой-то сценарий работы. В процессе записываем каждую нажатую клавишу и состояние буфера экрана. Потом берем новый код, который портировали полуавтоматическим методом, прогоняем те же клавиши и сравниваем экран терминала с эталоном после каждого шага. Если нет совпадения на 100%, значит что-то упустили.
Вторая задача - это уже обычная разработка (там можно использовать обычный инструментарий из AI Coding, но это не принципиально). Тут уже куча рисков, т.к. надо придумывать новый UI, писать под него тесты, отлаживать итп. Тут не просто механическое портирование кода, а думать надо. Но это типичная задача по разработке на достаточно современном языке программирования, ее решение известно. И этим можно заняться после первой задачи.
В общем, получается довольно забавный кейс, где использование LLM/AI - это не самоцель, а просто один из инструментов, который можно достаточно удобно вписать в картинку проекта на системном уровне. Можно даже обойтись и без него, но уж больно людей жалко.
Ваш, @llm_under_hood 🤗
Я давно не рассказывал про новые кейсы, т.к. проекты в основном встречаются повторяющиеся. В основном это data extraction - извлечение данных из PDF data sheets, purchase orders (с последующей сверкой или интеграцией). Иногда встречается какой-нибудь интересный поиск по документам.
Но вот появился принципиально новый интересный кейс применения LLM. На самом деле, он старый, но я лично с подобными масштабами не сталкивался.
Итак, есть одна компания, которой больше 100 лет. У нее есть своя самописная ERP система. Это система будет помоложе компании, и она написана на языке разработки бизнес-приложений со времен мейнфреймов, которому уже более 40 лет (для сравнения, 1C - моложе). БД в этой среде своя - проприетарная, интерфейс - терминал 80x25. Кода там - 700000 строчек, преимущественно CRUD и бизнес-логика рядом.
Это не IBM AS/400 с DB2, но что-то очень близкое по духу. Но и тут нужно платить дорогие лицензии, а разработчиков найти практически невозможно.
Компания хочет обновить код на что-то посовременнее. Не ради современности, а для того, чтобы были живые разработчики, которых можно нанять. Заодно клиент хочет еще и интерфейс сделать современным, но так, чтобы все горячие клавиши и последовательности символов работали, как раньше.
Соответственно, возник вопрос в системной оценке проекта - можно ли здесь как-нибудь ускорить процесс переписывания при помощи LLM, как вообще подходить к проекту, какие риски могут быть, как их лучше “вскрыть” пораньше?
И если начать копать, то получается интересная картина. В этой формулировке проекта компания смешала две разные задачи в одну кучу. И лучше бы их разделить, чтобы не умножать риски сверх нужды (я видел проекты, которые на этом погорели).
Первая задача - модернизация кода и перенос ERP системы с дремучего языка на JVM, без изменения терминального интерфейса. Функционал остается тот же самый, просто код читаем и не нужно платить адские суммы в год за лицензии.
Вторая задача - берем портированный и вычищенный код и уже свежими силами переписываем терминальный интерфейс на более “красивый” со всяким React/Desktop итп.
Так вот, в такой формулировке меньше всего рисков в первой части, т.к. можно использовать современные модели для ускорения анализа и переноса (Gemini Pro 2.5 очень удачно вышел). Но, самое главное - scope проекта: чтобы все работало точно так же, как и раньше, но только в браузере или в современном терминале.
А у терминальных приложений есть одна приятная черта - их достаточно просто протестировать на работу “точно так же”. Сажаем эксперта за оригинальное приложение, делаем snapshot БД и просим его реализовать какой-то сценарий работы. В процессе записываем каждую нажатую клавишу и состояние буфера экрана. Потом берем новый код, который портировали полуавтоматическим методом, прогоняем те же клавиши и сравниваем экран терминала с эталоном после каждого шага. Если нет совпадения на 100%, значит что-то упустили.
Вторая задача - это уже обычная разработка (там можно использовать обычный инструментарий из AI Coding, но это не принципиально). Тут уже куча рисков, т.к. надо придумывать новый UI, писать под него тесты, отлаживать итп. Тут не просто механическое портирование кода, а думать надо. Но это типичная задача по разработке на достаточно современном языке программирования, ее решение известно. И этим можно заняться после первой задачи.
В общем, получается довольно забавный кейс, где использование LLM/AI - это не самоцель, а просто один из инструментов, который можно достаточно удобно вписать в картинку проекта на системном уровне. Можно даже обойтись и без него, но уж больно людей жалко.
Ваш, @llm_under_hood 🤗
🔥69👍35🤩24❤14😁4💯1
Стоит ли делиться секретами разработки LLM систем с другими?
Когда-то меня спросили:
Все просто. Знания - это ценный ресурс. Они могут транслироваться в конкретную выгоду.
Скажем, если вовремя подсказать команде разработчиков правильный путь или подсветить потенциальные грабли, то можно сэкономить месяцы работы. А это не только финансовые затраты (часовая ставка * размер команды * пара месяцев), но и банально экономия того самого горячего времени, когда нужно ковать.
Знания можно набирать через опыт, исследования и практику, что тратит время. Может получиться так, что необходимо крутиться как белка в колесе только для того, чтобы быть в курсе основных вещей. Причем, если не крутиться, то может выйти так, что знания устаревают быстрее, чем их набираешь.
Чтобы не было такой печальной картины, мы можем использовать другую перспективу: Знания - это ценный ресурс, который должен работать. Их можно вкладывать!
Например, делиться инсайтами по тому, как быстрее и и проще реализовать бизнес-проекты с LLM под капотом. Или какие типы проектов выбирать, чтобы минимизировать риски и повысить отдачу. Рассказывать про SO CoT, тестирование систем и потенциальные проблемы с агентами и чат-ботами.
Это будет создавать среду, куда люди и компании приходят, узнавать новые вещи или закрепить уже услышанное. Некоторые будут даже обмениваться знаниями, приносить свои кейсы, или проблемы. Наш с вами чат, комьюнити наших курсов, группы близких по духу каналов - это как раз источники такой новой информации.
Если все эти разрозненные кусочки информации собирать и структурировать, то из этого будет рождаться уже действительно интересные инсайты и паттерны.
А ведь дальше можно сделать еще больше:
(1) организовывать публичные исследования вроде нашего Enterprise RAG Challenge или пулить ресурсы от нескольких компаний и запускать небольшие R&D проекты с лучшими специалистами по профилю.
(2) системно дополнять информацию о практике разработки систем с LLM под капотом информацией из других необходимых областей.
Когда мы в этом году проводили AI for Good инкубатор Мальты, то я думал, что стартапам будет больше всего нужна помощь с AI/LLM технологиями. Открыл материалы курса, приготовился вдумчиво консультировать.
А потом, когда начали работать со стартапами, то выяснилось, что техническая экспертиза у них уже хорошо закрыта общей насмотренностью и материалами курса. Времени было всего несколько месяцев, и полезнее всего было потратить его на воркшопы в смежных с AI областях - по разработке продуктовой стратегии для AI стартапов, коммуникациям, организации работы над продуктом, общению с инвесторами, выходу на рынок Европы, - и тому подобное.
В итоге мы вложили больше времени на отработку презентаций и навыков питчинга клиентам и инвесторам, нежели на техническую часть с AI/LLM.
В общем, практические знания о разработке систем с LLM под капотом - это ценный ресурс. Но они сами по себе - капля в море. Я считаю, что если над ними трястись и ничего с ними не делать - они просто устареют и растворятся. Куда лучше, если знания будут постоянно вкладываться, дополняться и двигать реальные проекты.
Cталкивались ли вы с ситуациями, когда распространение знаний помогло вам или вашей команде? Или, может быть, вы наоборот считаете, что открытость вредит конкурентным преимуществам?
Ваш, @llm_under_hood 🤗
Когда-то меня спросили:
Ринат, а стоит ли делиться инсайтами о проектах с LLM под капотом? Ведь тогда все это узнают, и ты уже будешь не нужен.
Все просто. Знания - это ценный ресурс. Они могут транслироваться в конкретную выгоду.
Скажем, если вовремя подсказать команде разработчиков правильный путь или подсветить потенциальные грабли, то можно сэкономить месяцы работы. А это не только финансовые затраты (часовая ставка * размер команды * пара месяцев), но и банально экономия того самого горячего времени, когда нужно ковать.
Знания можно набирать через опыт, исследования и практику, что тратит время. Может получиться так, что необходимо крутиться как белка в колесе только для того, чтобы быть в курсе основных вещей. Причем, если не крутиться, то может выйти так, что знания устаревают быстрее, чем их набираешь.
Чтобы не было такой печальной картины, мы можем использовать другую перспективу: Знания - это ценный ресурс, который должен работать. Их можно вкладывать!
Например, делиться инсайтами по тому, как быстрее и и проще реализовать бизнес-проекты с LLM под капотом. Или какие типы проектов выбирать, чтобы минимизировать риски и повысить отдачу. Рассказывать про SO CoT, тестирование систем и потенциальные проблемы с агентами и чат-ботами.
Это будет создавать среду, куда люди и компании приходят, узнавать новые вещи или закрепить уже услышанное. Некоторые будут даже обмениваться знаниями, приносить свои кейсы, или проблемы. Наш с вами чат, комьюнити наших курсов, группы близких по духу каналов - это как раз источники такой новой информации.
Если все эти разрозненные кусочки информации собирать и структурировать, то из этого будет рождаться уже действительно интересные инсайты и паттерны.
А ведь дальше можно сделать еще больше:
(1) организовывать публичные исследования вроде нашего Enterprise RAG Challenge или пулить ресурсы от нескольких компаний и запускать небольшие R&D проекты с лучшими специалистами по профилю.
(2) системно дополнять информацию о практике разработки систем с LLM под капотом информацией из других необходимых областей.
Когда мы в этом году проводили AI for Good инкубатор Мальты, то я думал, что стартапам будет больше всего нужна помощь с AI/LLM технологиями. Открыл материалы курса, приготовился вдумчиво консультировать.
А потом, когда начали работать со стартапами, то выяснилось, что техническая экспертиза у них уже хорошо закрыта общей насмотренностью и материалами курса. Времени было всего несколько месяцев, и полезнее всего было потратить его на воркшопы в смежных с AI областях - по разработке продуктовой стратегии для AI стартапов, коммуникациям, организации работы над продуктом, общению с инвесторами, выходу на рынок Европы, - и тому подобное.
В итоге мы вложили больше времени на отработку презентаций и навыков питчинга клиентам и инвесторам, нежели на техническую часть с AI/LLM.
В общем, практические знания о разработке систем с LLM под капотом - это ценный ресурс. Но они сами по себе - капля в море. Я считаю, что если над ними трястись и ничего с ними не делать - они просто устареют и растворятся. Куда лучше, если знания будут постоянно вкладываться, дополняться и двигать реальные проекты.
Cталкивались ли вы с ситуациями, когда распространение знаний помогло вам или вашей команде? Или, может быть, вы наоборот считаете, что открытость вредит конкурентным преимуществам?
Ваш, @llm_under_hood 🤗
🤝72🔥48👍26❤19🥰6🤗5🤯4😱1💯1
OpenAI Codex - по ощущениям похоже на Deep Research в своих проектах
Подключаешь к Github, даешь доступ к проекту и запускаешь задачи. И оно что-то там крутит и копошится, примерно как o1 pro / Deep Research. Только вместо поиска в сети оно работает с кодом в контейнере - запускает утилиты и пытается прогонять тесты (если они есть). Цепочку рассуждений можно проверить.
По результатам - создает Pull Request с изменениями, который можно просмотреть и отправить обратно в Github.
Потенциально выглядит весьма интересно. Deep Research и планировщику OpenAI я доверяю. А тут прямо можно поставить в очередь ряд задач и переключиться на другие дела.
А как это в сравнении с Cursor.sh?
Как говорят люди, это аналогично по качеству Cursor + Gemini 2.5-pro. Но возможность удобно и легко запускать параллельные задачи - это что-то новое (перевод цитаты с HN):
Ваш, @llm_under_hood 🤗
Подключаешь к Github, даешь доступ к проекту и запускаешь задачи. И оно что-то там крутит и копошится, примерно как o1 pro / Deep Research. Только вместо поиска в сети оно работает с кодом в контейнере - запускает утилиты и пытается прогонять тесты (если они есть). Цепочку рассуждений можно проверить.
По результатам - создает Pull Request с изменениями, который можно просмотреть и отправить обратно в Github.
Потенциально выглядит весьма интересно. Deep Research и планировщику OpenAI я доверяю. А тут прямо можно поставить в очередь ряд задач и переключиться на другие дела.
А как это в сравнении с Cursor.sh?
Как говорят люди, это аналогично по качеству Cursor + Gemini 2.5-pro. Но возможность удобно и легко запускать параллельные задачи - это что-то новое (перевод цитаты с HN):
По ощущениям, это словно младший инженер на стероидах: достаточно указать файл или функцию и описать необходимое изменение, после чего модель подготовит основную структуру пул-реквеста. Всё равно приходится делать много работы, чтобы довести результат до продакшн-уровня, однако теперь у вас как будто в распоряжении бесконечное число младших разработчиков, каждый из которых занимается своей задачей.
Ваш, @llm_under_hood 🤗
❤66👍23🔥5🥰5🤯1🤣1
Проваливается ли Apple в гонке за AI?
@techsparks перепостил заметку, с которой я категорически не согласен:
Нет. Наоборот, Apple, как никто другой понимает важность выпуска стабильного и надежного продукта.
С AI можно такие продукты делать, но (если качество результата важно) это занимает очень много времени. Тестирование, работа с галлюцинациями и стабилизация AI пайплайнов требуют больше усилий, чем кажется. Apple недооценила объем работ, бывает.
И я восхищаюсь их выдержкой. Вместо того, чтобы выкатывать сырой продукт, они сорвали сроки и взяли время на доделку.
Это скорее свидетельствует о том, что они серьезно подходят к продукту и будут стремиться выдерживать планку качества. Всем бы так подходить к продуктам с LLM под капотом.
Ваш, @llm_under_hood 🤗
@techsparks перепостил заметку, с которой я категорически не согласен:
Apple тихо и красиво проваливается в главной гонке десятилетия — гонке за искусственный интеллект. Bloomberg написал длинный текст о том, как всё пошло не так: Siri с якобы встроенным ИИ оказалась всё той же вежливой скрепкой из 2011-го года, просто теперь ошибающейся в большем количестве сценариев (в трети, если быть точным).
Нет. Наоборот, Apple, как никто другой понимает важность выпуска стабильного и надежного продукта.
С AI можно такие продукты делать, но (если качество результата важно) это занимает очень много времени. Тестирование, работа с галлюцинациями и стабилизация AI пайплайнов требуют больше усилий, чем кажется. Apple недооценила объем работ, бывает.
И я восхищаюсь их выдержкой. Вместо того, чтобы выкатывать сырой продукт, они сорвали сроки и взяли время на доделку.
Это скорее свидетельствует о том, что они серьезно подходят к продукту и будут стремиться выдерживать планку качества. Всем бы так подходить к продуктам с LLM под капотом.
Ваш, @llm_under_hood 🤗
❤77👍49🤣44🔥10🤔10😁3
Я пару дней пользовался OpenAI Codex. Это не панацея, но при этом прорывная в своем роде штука.
Codex - это среда для AI + Coding. Сразу предупрежу, что качество работы с кодом примерно сравнимо с тем, что уже можно получить с Cursor + Gemini Pro 2.5. Тут нет ничего нового.
Есть один нюанс. Разработку в Cursor + Gemini Pro 2.5 или Aider надо вести самостоятельно, выдавая задачи, отслеживая проблемы и проверяя результаты. За один раз можно вести один проект.
Есть еще альтернативный подход к разработке - запускать агентов, которые сами будут что-то планировать и копошиться в папке с проектом. Но, как я писал, иногда агенты только создают иллюзию работы, растягивая на 30-120 минут задачи, которые можно решить одним промптом в чате.
А что нового предложил OpenAI Codex?
Они сделали все красиво и удобно. Можно к своему аккаунту подключить несколько github repositories и запускать задачи текстом (примеры ниже). Это похоже на работу DeepResearch, но с кодом. Поставил задачу и пошел по своим делам, а reasoning планировщик от OpenAI проследит за выполнением работы. Он заберет код, прочитает инструкции, сам найдет нужные файлы, попробует изменить их, прогонит тесты итп. А в итоге упакует все изменения в Pull Requests, который можно будет по отдельности просмотреть и принять либо отклонить.
И тут есть две фишки.
Во-первых, планировщик OpenAI работает достаточно хорошо. Примерно треть его Pull Requests можно отправлять прямо в код (половину, если проект простой).
А ведь еще можно допилить проект, чтобы Codex-у было удобнее работать. Докинуть AGENTS.MD с инструкциями, добавить хорошие тесты, модульную архитектуру и комментарии. Все фишки оформления проектов для работы с AI+Coding, про которые мы говорили на вебинарах в прошлом году - тут как раз применимы.
И это все работает стабильно потому, что OpenAI выбрали всего несколько инструментов для своего “агента”, очень хорошо протестировали и отладили все. Это было возможно потому, что у Codex нет кучи инструментов - только консоль и работа с файлами.
Хотя, казалось бы, дай кодексу возможность работать с любыми MCP серверами, как это нынче сделала Microsoft, и получится продукт-бомба. Но OpenAI хорошо понимает, что в таком случае ни о каком покрытии тестами нельзя вести речь. А значит и прощай стабильность и привет галлюцинации.
Во-вторых, в Codex можно запускать одновременно несколько задач. Каждая из них будет запущена в отдельном контейнере. И вот это как раз кардинально меняет весь подход. Можно, скажем, сказать:
(1) добавь мне шифрование паролей с bcrypt
(2) перепиши доступ к БД с sqlite3 на синхронный better-sqlite3
(3) отладь вот эту ошибку в тестах
и сразу в другом проекте, который совершенно не относится к первому:
(4) напиши тесты к wifi_manager component
(5) сделай, чтобы система переподключалась при проблемах с wifi или websocket
и идти пить кофе. А потом вернуться, посмотреть отчеты с Pull Requests и задать новые задачи.
Получился очень классный продукт для разработки. Это как несколько очень усидчивых Джунов, которые могут помогать разрабатывать несколько проектов одновременно.
Понятно, что есть пара нюансов:
(1) OpenAI Codex - не панацея, он дополняет опытных разработчиков, не заменяет
(2) Среда очень ограниченная, и там есть нюансы (например, e2e browser testing я так пока там не смог запустить)
(3) нужна практика, чтобы освоить инструмент и научиться так формировать проекты, что Codex будет с ними хорошо работать.
Ну и самое главное, OpenAI наглядно показали, что агенты могут работать очень хорошо, если собрать правильный продукт, докинуть туда хорошую reasoning модель и обеспечить приемлемое качество. И тут хорошо выстреливает модель - выдал задания и ушел по своим делам/пить кофе.
Теперь осталось подождать, пока другие компании воспользуются этим примером! Особенно будет интересно увидеть подобные решения не в кодинге, а в бизнес-задачах.
Ваш, @llm_under_hood 🤗
PS: Хотите запустить локально без красивого UI? См OpenAI Codex CLI
Codex - это среда для AI + Coding. Сразу предупрежу, что качество работы с кодом примерно сравнимо с тем, что уже можно получить с Cursor + Gemini Pro 2.5. Тут нет ничего нового.
Есть один нюанс. Разработку в Cursor + Gemini Pro 2.5 или Aider надо вести самостоятельно, выдавая задачи, отслеживая проблемы и проверяя результаты. За один раз можно вести один проект.
Есть еще альтернативный подход к разработке - запускать агентов, которые сами будут что-то планировать и копошиться в папке с проектом. Но, как я писал, иногда агенты только создают иллюзию работы, растягивая на 30-120 минут задачи, которые можно решить одним промптом в чате.
А что нового предложил OpenAI Codex?
Они сделали все красиво и удобно. Можно к своему аккаунту подключить несколько github repositories и запускать задачи текстом (примеры ниже). Это похоже на работу DeepResearch, но с кодом. Поставил задачу и пошел по своим делам, а reasoning планировщик от OpenAI проследит за выполнением работы. Он заберет код, прочитает инструкции, сам найдет нужные файлы, попробует изменить их, прогонит тесты итп. А в итоге упакует все изменения в Pull Requests, который можно будет по отдельности просмотреть и принять либо отклонить.
И тут есть две фишки.
Во-первых, планировщик OpenAI работает достаточно хорошо. Примерно треть его Pull Requests можно отправлять прямо в код (половину, если проект простой).
А ведь еще можно допилить проект, чтобы Codex-у было удобнее работать. Докинуть AGENTS.MD с инструкциями, добавить хорошие тесты, модульную архитектуру и комментарии. Все фишки оформления проектов для работы с AI+Coding, про которые мы говорили на вебинарах в прошлом году - тут как раз применимы.
И это все работает стабильно потому, что OpenAI выбрали всего несколько инструментов для своего “агента”, очень хорошо протестировали и отладили все. Это было возможно потому, что у Codex нет кучи инструментов - только консоль и работа с файлами.
Хотя, казалось бы, дай кодексу возможность работать с любыми MCP серверами, как это нынче сделала Microsoft, и получится продукт-бомба. Но OpenAI хорошо понимает, что в таком случае ни о каком покрытии тестами нельзя вести речь. А значит и прощай стабильность и привет галлюцинации.
Во-вторых, в Codex можно запускать одновременно несколько задач. Каждая из них будет запущена в отдельном контейнере. И вот это как раз кардинально меняет весь подход. Можно, скажем, сказать:
(1) добавь мне шифрование паролей с bcrypt
(2) перепиши доступ к БД с sqlite3 на синхронный better-sqlite3
(3) отладь вот эту ошибку в тестах
и сразу в другом проекте, который совершенно не относится к первому:
(4) напиши тесты к wifi_manager component
(5) сделай, чтобы система переподключалась при проблемах с wifi или websocket
и идти пить кофе. А потом вернуться, посмотреть отчеты с Pull Requests и задать новые задачи.
Получился очень классный продукт для разработки. Это как несколько очень усидчивых Джунов, которые могут помогать разрабатывать несколько проектов одновременно.
Понятно, что есть пара нюансов:
(1) OpenAI Codex - не панацея, он дополняет опытных разработчиков, не заменяет
(2) Среда очень ограниченная, и там есть нюансы (например, e2e browser testing я так пока там не смог запустить)
(3) нужна практика, чтобы освоить инструмент и научиться так формировать проекты, что Codex будет с ними хорошо работать.
Ну и самое главное, OpenAI наглядно показали, что агенты могут работать очень хорошо, если собрать правильный продукт, докинуть туда хорошую reasoning модель и обеспечить приемлемое качество. И тут хорошо выстреливает модель - выдал задания и ушел по своим делам/пить кофе.
Теперь осталось подождать, пока другие компании воспользуются этим примером! Особенно будет интересно увидеть подобные решения не в кодинге, а в бизнес-задачах.
Ваш, @llm_under_hood 🤗
PS: Хотите запустить локально без красивого UI? См OpenAI Codex CLI
👍78🔥32❤20😁1
Есть вопросы про Domain-Driven Design и AI?
В нашем комьюнити есть люди, которые слышали про Domain-Driven Design или даже используют методы оттуда. Чаще всего это встречается в сложных областях и больших корпоративных проектах.
Я сам постоянно опираюсь на DDD в проектах. Во-первых, DDD сильно помогает приземлять сложные проекты в реальность, изолировать домены и организовывать работу разных команд (которые не всегда дружат). Во-вторых, DDD - как методология уделяющая особенное внимание языку - очень хорошо помогает в разработке решений с Large Language Models под капотом.
Какие вопросы в рамках темы данного канала вы бы хотели задать Эрику Эвансу - автору Domain-Driven Design?
Ваш, @llm_under_hood 🤗
В нашем комьюнити есть люди, которые слышали про Domain-Driven Design или даже используют методы оттуда. Чаще всего это встречается в сложных областях и больших корпоративных проектах.
Я сам постоянно опираюсь на DDD в проектах. Во-первых, DDD сильно помогает приземлять сложные проекты в реальность, изолировать домены и организовывать работу разных команд (которые не всегда дружат). Во-вторых, DDD - как методология уделяющая особенное внимание языку - очень хорошо помогает в разработке решений с Large Language Models под капотом.
Какие вопросы в рамках темы данного канала вы бы хотели задать Эрику Эвансу - автору Domain-Driven Design?
Ваш, @llm_under_hood 🤗
🔥31❤9🤩5👍2🤝2
Чем отличается OpenAI Codex от Claude Code / Aider / Cursor итп? Одной картинкой.
Можно запустить разные задачи на разных проектах прямо с телефона.
Ваш, @llm_under_hood 🤗
Можно запустить разные задачи на разных проектах прямо с телефона.
Ваш, @llm_under_hood 🤗
🔥47🤔14🤯8❤3👍3🎄1
Человек, который разбирается в DDD, подтвердил, что AI проекты со стороны кажутся слишком непредсказуемыми и сложными для опытных интеграторов.
Но если посмотреть на все с точки зрения статистики успешных кейсов и рабочих паттернов, то начинает вырисовыватся интересная картинка. Просто у них пока не было такой статистики и перспективы.
Будем исправлять.
Ваш, @llm_under_hood 🤗
PS: Ваши вопросы я задать не успел, но они уже пригодились. Спасибо! Я их приберегу на потом.
Но если посмотреть на все с точки зрения статистики успешных кейсов и рабочих паттернов, то начинает вырисовыватся интересная картинка. Просто у них пока не было такой статистики и перспективы.
Будем исправлять.
Ваш, @llm_under_hood 🤗
PS: Ваши вопросы я задать не успел, но они уже пригодились. Спасибо! Я их приберегу на потом.
🤩35👍27🔥8❤6😁6👏3🤝2🤣1
Кейс - локальный ассистент по работе с технической и регламентной документацией.
Это цитата Alex U из нашего чата. Можно посмотреть обсуждение и задать дополнительные вопросы тут.
Ваш, @llm_under_hood 🤗
PS: Если заходите в чат впервые, пожалуйста, не игнорируйте сообщения от бота спам-защиты.
У нас был кейс - ассистент по работе с оборудованием (нефтегаз, upstream). Много технической и регламентной документации. Пайплайн - таксономия по документам и разделам, фильтрация документов и роутинг по запросу, семантический чанкинг, гибридный поиск, LLM Reranker, еще ветка на text2SQL (отдельная экстракция табличных данных), обогащение контекста. Answer relevance финальной генерации рос почти пропорционально размеру модели (Qwen) в экспериментах, где все релевантные чанки были в контексте (recall = 100%). Остановились на 70B. Ниже не устраивало заказчика по качеству, а 70В было еще приемлемо по цене (2xA100). Датасет - несколько тысяч запросов.
Это цитата Alex U из нашего чата. Можно посмотреть обсуждение и задать дополнительные вопросы тут.
Ваш, @llm_under_hood 🤗
PS: Если заходите в чат впервые, пожалуйста, не игнорируйте сообщения от бота спам-защиты.
👍32🔥18❤7
А могут ли современные AI+Coding инструменты справиться с большими проектами? Например, самостоятельно добавить фичу в SaaS продукт?
Такой вопрос мне постоянно задают опытные разработчики. Их скепсис понятен. Если мелкие утилитки и прототипы Claude или Gemini Pro ещё осилят, то вот разрабатывать самостоятельно большие приложения с кучей зависимостей и нюансов - уже сложнее.
Разработчики говорят, что агенты вечно упускают из виду важные нюансы или даже просто несут пургу.
А какой у вас опыт использования AI+Coding инструментов для разработки фич в приложениях?
Ваш, @llm_under_hood 🤗
PS: Тема интересная. Давайте в дискуссии не будем переходить на личности и будем уважительны.
Задача - не доказать что-то, а вместе разобраться.
Такой вопрос мне постоянно задают опытные разработчики. Их скепсис понятен. Если мелкие утилитки и прототипы Claude или Gemini Pro ещё осилят, то вот разрабатывать самостоятельно большие приложения с кучей зависимостей и нюансов - уже сложнее.
Разработчики говорят, что агенты вечно упускают из виду важные нюансы или даже просто несут пургу.
А какой у вас опыт использования AI+Coding инструментов для разработки фич в приложениях?
Ваш, @llm_under_hood 🤗
PS: Тема интересная. Давайте в дискуссии не будем переходить на личности и будем уважительны.
Задача - не доказать что-то, а вместе разобраться.
👍32❤17🔥11😱1💯1
Вайб-кодить стало проще. Мелкие прототипы и утилиты делать с AI - милое дело.
Вообще, чем моложе код, тем лучше с ним справятся AI+Coding инструменты. И это меняет существующий уклад.
Раньше все парадигмы разработки продуктов строились на том, что разработка дорогая и долгая. Поэтому нужно было десять раз поговорить с клиентами, прежде чем запускать разработку одного прототипа.
Сейчас можно запускать MVP и собирать feedback гораздо быстрее. Главное, чтобы были люди, которые умеют работать с продуктовыми гипотезами.
Понятно, если продукт выстрелит, то его потребуется развивать. Новые фичи, масштабирование, безопасность, версионирование БД и API итп. И тогда уже нужен будет опытный старший брат/пастух, который будет присматривать за стадом из AI+Coding агентов, ловить косяки и периодически чистить техдолг.
Чем сложнее и старше система, тем больше там накапливается нюансов и особенностей. Тем больше там граблей, на которые могут наступить агенты.
Поэтому, когда заходит речь про AI+Coding, то мнения про него нередко поляризуются. Кто-то считает, что AI может справиться с любыми задачами. Кто-то считает, что AI галлюцинирует и делает глупые ошибки.
Чаще всего, в первом лагере те люди, которые работают с молодыми продуктами и небольшими прототипами. Во втором лагере те, кто работает с проектами старше нескольких лет от роду, с накопившейся сложностью и техдолгом.
Понятно, что представление про “два лагеря” - упрощенное, для иллюстрации. В реальности спектр проектов поразнобразнее.
Ведь можно за 30 минут нагенерить такую кашу, что этот молодой проект проще закопать сразу. А еще можно взять проект посложнее и поставить там хорошую архитектуру и среду для AI: оптимизировать стэк, разбить проект на модули, обвязать тестами, хорошей документацией и декомпозировать задачи. Тогда нужно будет реже вмешиваться в работу агентов, засучивать рукава и чистить техдолг.
Но в итоге все сводится к одному - чем старше проект, тем хуже работает вайб-кодинг, тем легче там AI+Coding агентам заблудиться без постороннего пригляда.
Ваш, @llm_under_hood 🤗
Вообще, чем моложе код, тем лучше с ним справятся AI+Coding инструменты. И это меняет существующий уклад.
Раньше все парадигмы разработки продуктов строились на том, что разработка дорогая и долгая. Поэтому нужно было десять раз поговорить с клиентами, прежде чем запускать разработку одного прототипа.
Сейчас можно запускать MVP и собирать feedback гораздо быстрее. Главное, чтобы были люди, которые умеют работать с продуктовыми гипотезами.
Понятно, если продукт выстрелит, то его потребуется развивать. Новые фичи, масштабирование, безопасность, версионирование БД и API итп. И тогда уже нужен будет опытный старший брат/пастух, который будет присматривать за стадом из AI+Coding агентов, ловить косяки и периодически чистить техдолг.
Чем сложнее и старше система, тем больше там накапливается нюансов и особенностей. Тем больше там граблей, на которые могут наступить агенты.
Поэтому, когда заходит речь про AI+Coding, то мнения про него нередко поляризуются. Кто-то считает, что AI может справиться с любыми задачами. Кто-то считает, что AI галлюцинирует и делает глупые ошибки.
Чаще всего, в первом лагере те люди, которые работают с молодыми продуктами и небольшими прототипами. Во втором лагере те, кто работает с проектами старше нескольких лет от роду, с накопившейся сложностью и техдолгом.
Понятно, что представление про “два лагеря” - упрощенное, для иллюстрации. В реальности спектр проектов поразнобразнее.
Ведь можно за 30 минут нагенерить такую кашу, что этот молодой проект проще закопать сразу. А еще можно взять проект посложнее и поставить там хорошую архитектуру и среду для AI: оптимизировать стэк, разбить проект на модули, обвязать тестами, хорошей документацией и декомпозировать задачи. Тогда нужно будет реже вмешиваться в работу агентов, засучивать рукава и чистить техдолг.
Но в итоге все сводится к одному - чем старше проект, тем хуже работает вайб-кодинг, тем легче там AI+Coding агентам заблудиться без постороннего пригляда.
Ваш, @llm_under_hood 🤗
❤71👍40🔥22💯9🤔3😁2🤗2
Как разрабатывать большие проекты с кучей зависимостей?
Я сейчас пишу вторую версию своей учебной платформы при помощи OpenAI Codex. Эта версия похожа на ту, на которой расположен мой курс про AI Ассистентов, но в нее хочется добавить больше фич: удобное управление командными пакетами, больше интерактивных задачек и примеров, тесты для самопроверки.
95% кода пока написаны OpenAI Codex. Но есть нюанс.
Сначала я дам контекст и кратко расскажу о проекте, а потом опишу процесс AI+Coding.
О проекте
Архитектуру и стэк проекта я оптимизировал для удобства разработки AI (сам я бы на TS/JS в жизни не стал писать):
- Frontend - Vue.js SPA
- Backend - Express.js, tRPC, SQLite (ибо тесты в контейнере можно запускать)
- Shared - общие для FE/BE типы и контракты на TypeScript/Zod. Ключевая терминология (DDD) кодифицирована там же.
Конкретные библиотеки выбирал при помощи ChatGPT, которому ставил задачи выбирать наиболее стабильные и скучные решения (читай "они точно попали в обучающую выборку OpenAI").
Серверная обвязка - NixOS. Есть интеграции со страйпом, почтой. End-to-end тесты сделаны на playwright. Пришлось повозиться, пока встраивал их в Codex, но теперь он может сам запускать весь стэк, открывать браузер и прогонять тесты перед сочинением Pull Request.
Легковесные очереди. Виртуализация sandboxes будет через FirecrackerVM.
Continuous Integration / Deployment - Github Actions. После того, как я принял Pull Request, GA автоматом выкатит все на DEV stage.
Процесс разработки
Процесс разработки работает аналогично работе команд над большими проектами:
- я ставлю задачу
- AI предлагает решение
- я просматриваю и одобряю
- AI кодит и отправляет в Git
Этот процесс "обрастает” артефактами и правилами, делающими его прозрачным и предсказуемым для людей (меня), и для LLM-ок в команде.
1️⃣ У меня есть архитектурная документация и описание модулей (README, AGENTS, CONTEXT). Это все живет рядом с кодом, я стараюсь поддерживать это в актуальном состоянии.
2️⃣ При постановке задачи я первым делом прошу систему составить детальный план реализации (implementation plan), включая зависимости и тесты. Не писать код, а просто подумать. Если задачка сложная - явно укажу документы, на которые стоит обратить внимание, зависимости.
Кстати, ChatGPT reasonong (не Codex) может тоже работать с Github. Это иногда упрощает работу с планами.
3️⃣ План реализации - это единственный источник правды. Я его проглядываю глазами. При необходимости отправляю его в другую сессию и прошу проверить на логические нестыковки.
Это очень удобно, т.к. все изменения в одном документе, они пока еще не “размазаны” по коду.
4️⃣ Если план реализации проходит мой review, то я его отправляю на исполнение. Потом план можно выкинуть или скопировать в Pull Request на память.
Можно не жалеть AI+Coding агентов игонять в хвост и в гриву - всегда запускать сразу несколько параллельных задач, чтобы потом выбрать наилучший вариант.
Полет пока нормальный. Это не вайб кодинг, а рутинная работа архитектора/лида. Задачи распараллеливаются, но думать - надо. При этом результат предсказуем, а весь код таки пишет AI.
Ваш, @llm_under_hood 🤗
Я сейчас пишу вторую версию своей учебной платформы при помощи OpenAI Codex. Эта версия похожа на ту, на которой расположен мой курс про AI Ассистентов, но в нее хочется добавить больше фич: удобное управление командными пакетами, больше интерактивных задачек и примеров, тесты для самопроверки.
95% кода пока написаны OpenAI Codex. Но есть нюанс.
Сначала я дам контекст и кратко расскажу о проекте, а потом опишу процесс AI+Coding.
О проекте
Архитектуру и стэк проекта я оптимизировал для удобства разработки AI (сам я бы на TS/JS в жизни не стал писать):
- Frontend - Vue.js SPA
- Backend - Express.js, tRPC, SQLite (ибо тесты в контейнере можно запускать)
- Shared - общие для FE/BE типы и контракты на TypeScript/Zod. Ключевая терминология (DDD) кодифицирована там же.
Конкретные библиотеки выбирал при помощи ChatGPT, которому ставил задачи выбирать наиболее стабильные и скучные решения (читай "они точно попали в обучающую выборку OpenAI").
Серверная обвязка - NixOS. Есть интеграции со страйпом, почтой. End-to-end тесты сделаны на playwright. Пришлось повозиться, пока встраивал их в Codex, но теперь он может сам запускать весь стэк, открывать браузер и прогонять тесты перед сочинением Pull Request.
Легковесные очереди. Виртуализация sandboxes будет через FirecrackerVM.
Continuous Integration / Deployment - Github Actions. После того, как я принял Pull Request, GA автоматом выкатит все на DEV stage.
Процесс разработки
Процесс разработки работает аналогично работе команд над большими проектами:
- я ставлю задачу
- AI предлагает решение
- я просматриваю и одобряю
- AI кодит и отправляет в Git
Этот процесс "обрастает” артефактами и правилами, делающими его прозрачным и предсказуемым для людей (меня), и для LLM-ок в команде.
1️⃣ У меня есть архитектурная документация и описание модулей (README, AGENTS, CONTEXT). Это все живет рядом с кодом, я стараюсь поддерживать это в актуальном состоянии.
2️⃣ При постановке задачи я первым делом прошу систему составить детальный план реализации (implementation plan), включая зависимости и тесты. Не писать код, а просто подумать. Если задачка сложная - явно укажу документы, на которые стоит обратить внимание, зависимости.
Кстати, ChatGPT reasonong (не Codex) может тоже работать с Github. Это иногда упрощает работу с планами.
3️⃣ План реализации - это единственный источник правды. Я его проглядываю глазами. При необходимости отправляю его в другую сессию и прошу проверить на логические нестыковки.
Это очень удобно, т.к. все изменения в одном документе, они пока еще не “размазаны” по коду.
4️⃣ Если план реализации проходит мой review, то я его отправляю на исполнение. Потом план можно выкинуть или скопировать в Pull Request на память.
Можно не жалеть AI+Coding агентов и
Полет пока нормальный. Это не вайб кодинг, а рутинная работа архитектора/лида. Задачи распараллеливаются, но думать - надо. При этом результат предсказуем, а весь код таки пишет AI.
Ваш, @llm_under_hood 🤗
👍146🔥69❤29🤔5🤗5⚡4🤣1
Кто еще использует AI+Coding на проектах 5k - 1M+ строк кода?
В прошлом посте я рассказал про свой опыт использования AI+Coding на небольшом проекте(6k loc full-stack monorepo проекте учебной платформы).
Схожий опыт - в Homai (22k C++ кода, 9k Python, 3k Go, HTML/JS - по мелочам). @AigizK без AI/Codex уже жить не может.
@underbird в чате рассказал про опыт работы над проектом в 100k строчек кода, где AI сильно ускоряет процесс разработки.
Все это не про вайб-кодинг. Он на больших проектах не работает.
У кого еще есть успешный опыт ускорения процесса разработки в больших проектах (больше 5k активного кода) при помощи AI+Coding? Расскажите про свой опыт!
Ваш, @llm_under_hood 🤗
В прошлом посте я рассказал про свой опыт использования AI+Coding на небольшом проекте(6k loc full-stack monorepo проекте учебной платформы).
Схожий опыт - в Homai (22k C++ кода, 9k Python, 3k Go, HTML/JS - по мелочам). @AigizK без AI/Codex уже жить не может.
@underbird в чате рассказал про опыт работы над проектом в 100k строчек кода, где AI сильно ускоряет процесс разработки.
Все это не про вайб-кодинг. Он на больших проектах не работает.
У кого еще есть успешный опыт ускорения процесса разработки в больших проектах (больше 5k активного кода) при помощи AI+Coding? Расскажите про свой опыт!
Ваш, @llm_under_hood 🤗
🔥38❤12💯7🥰5🤯3🤣2
Что бывает, если дать разработчикам 8 часов и AI - 7 примеров
(Скриншоты 7 утилит, которые были полностью написаны AI - в комментариях, тут - контекст и оглавление)
У меня сейчас закончился первый модуль экспериментального курса AI+Coding. Он проводился в одной компании и был посвящен основам разработки при помощи AI. Мы изучали различные инструменты кодинга с AI, отрабатывали практические задания и осваивали процесс быстрого создания простых утилит.
Cегодня участники показывали всей компании результаты своей работы. У них была “выпускная” задача - при помощи AI+Coding за 4-8 часов создать утилиту, которая сделает их работу на основном проекте более легкой и приятной.
Это задание выполняли разные люди с разным опытом из разных проектов. Вот что они сделали:
(1) Инструмент для анализа корпоративных систем на сотни тысяч строк кода на 4GL языке
(2) Утилита для удобного редактирования словарей Contextive (работа с DDD)
(3) Тулза, которая помогает накатывать архитектурные изменения в DS/ML проектах (когда нужно синхронизировать десятки проектов)
(4) Extension для Cursor - ему задаешь вопрос текстом, а он генерит Regex, который найдет нужные файлы
(5) Красивая тулза, которая подключается прямо к Azure DevOps, описывает проект и отвечает на вопросы по коду
(6) Инструмент, который анализирует Docker build logs и визуализирует узкие места в процессе сборки контейнеров
(7) Автоматический анализатор тестов, которые проходят кандидаты в одну компанию газированных напитков (вы видели ее продукты в магазине) на предмет выявления очевидных ботов.
И это было очень круто видеть! Я не ожидал такого разнообразия способов упросить работу на типичных проектах. Ребята взяли самые нудные или наболевшие моменты своей работы и просто избавились от них.
Самое интересное, что весь этот процесс был заказан директором компании, как попытка мотивировать сотрудников в том, чтобы хотя бы начать интересоваться AI. Предварительная его оценка - “Отлично!”
Осталось дождаться результатов - смогут ли эти примеры вдохновить и других сотрудников начать осваивать AI? KPI - сколько еще людей попросятся во второй поток этого курса в данной компании.
Скриншоты этих семи утилит - в комментариях.
А если бы у вас в компании был подобный эксперимент, какую бы утилиту хотели сделать вы?
Ваш, @llm_under_hood 🤗
(Скриншоты 7 утилит, которые были полностью написаны AI - в комментариях, тут - контекст и оглавление)
У меня сейчас закончился первый модуль экспериментального курса AI+Coding. Он проводился в одной компании и был посвящен основам разработки при помощи AI. Мы изучали различные инструменты кодинга с AI, отрабатывали практические задания и осваивали процесс быстрого создания простых утилит.
Cегодня участники показывали всей компании результаты своей работы. У них была “выпускная” задача - при помощи AI+Coding за 4-8 часов создать утилиту, которая сделает их работу на основном проекте более легкой и приятной.
Это задание выполняли разные люди с разным опытом из разных проектов. Вот что они сделали:
(1) Инструмент для анализа корпоративных систем на сотни тысяч строк кода на 4GL языке
(2) Утилита для удобного редактирования словарей Contextive (работа с DDD)
(3) Тулза, которая помогает накатывать архитектурные изменения в DS/ML проектах (когда нужно синхронизировать десятки проектов)
(4) Extension для Cursor - ему задаешь вопрос текстом, а он генерит Regex, который найдет нужные файлы
(5) Красивая тулза, которая подключается прямо к Azure DevOps, описывает проект и отвечает на вопросы по коду
(6) Инструмент, который анализирует Docker build logs и визуализирует узкие места в процессе сборки контейнеров
(7) Автоматический анализатор тестов, которые проходят кандидаты в одну компанию газированных напитков (вы видели ее продукты в магазине) на предмет выявления очевидных ботов.
И это было очень круто видеть! Я не ожидал такого разнообразия способов упросить работу на типичных проектах. Ребята взяли самые нудные или наболевшие моменты своей работы и просто избавились от них.
Самое интересное, что весь этот процесс был заказан директором компании, как попытка мотивировать сотрудников в том, чтобы хотя бы начать интересоваться AI. Предварительная его оценка - “Отлично!”
Осталось дождаться результатов - смогут ли эти примеры вдохновить и других сотрудников начать осваивать AI? KPI - сколько еще людей попросятся во второй поток этого курса в данной компании.
Скриншоты этих семи утилит - в комментариях.
А если бы у вас в компании был подобный эксперимент, какую бы утилиту хотели сделать вы?
Ваш, @llm_under_hood 🤗
🔥86❤21👍7🤔1🤣1
LLM Бенчмарк Claude 4
Модель Claude Sonnet 4, которой пользуется большинство, значительно выросла в очках сравнению со своим предшественником - Sonnet 3.7. Причем, прогресс есть во всех категориях, кроме сложных BI задач.
Кстати, пусть Claude Sonnet и не в топах по работе с зубодробительным кодом и легаси решениями, но если нужно быстро набросать симпатичный web интерфейс, то альтернативе Sonnet пока нет.
Claude Opus 4 - стал немного хуже, чем Claude 3.7 Sonnet Thinking
Ваш, @llm_under_hood 🤗
PS: Прочитать про мой подход к бенчмаркам можно тут. Там есть и FAQ со всеми вопросами, которые задают последние полтора года. Пожалуйста, прочитайте его, прежде чем оставлять свой первый комментарий.
Модель Claude Sonnet 4, которой пользуется большинство, значительно выросла в очках сравнению со своим предшественником - Sonnet 3.7. Причем, прогресс есть во всех категориях, кроме сложных BI задач.
Кстати, пусть Claude Sonnet и не в топах по работе с зубодробительным кодом и легаси решениями, но если нужно быстро набросать симпатичный web интерфейс, то альтернативе Sonnet пока нет.
Claude Opus 4 - стал немного хуже, чем Claude 3.7 Sonnet Thinking
Ваш, @llm_under_hood 🤗
PS: Прочитать про мой подход к бенчмаркам можно тут. Там есть и FAQ со всеми вопросами, которые задают последние полтора года. Пожалуйста, прочитайте его, прежде чем оставлять свой первый комментарий.
❤21🎉19👍8🤝3🔥1
Знаете, как опытные дизайнеры используют AI?
Они говорят, что AI - это творческая и непредсказуемая штука:
(цитата из внутренней переписки, переведена GPT-4.5)
И чтобы работать с пространствами вероятностей, дизайнеры сначала вместе с AI составляют планы и описания желаемых результатов. Они фиксируют в плане те вещи, которые должны четко быть отражены в результатах. А те моменты, где нужна непредсказуемость и вариативность - оставляют на “откуп” моделям.
Потом они запускают план несколько раз и выбирают понравившийся вариант. Если во всех реализациях схожие ошибки - они правят план и перезапускают.
Аналогично используют AI и копирайтеры (люди, которые пишут тексты). Сначала они вместе с AI собирают планы для написания текста (outlines), в которых прописывают важные факты, цитаты, структуру - все те вещи, которые нужно фиксировать. А потом отдают план LLM-ке на “разворачивание” в черновик текста. Причем, генерируют несколько вариантов текста, чтобы выбрать наиболее симпатичный для дальнейшей доводки.
Везде работает один и тот же принцип:
(1) сначала разрабатываем план реализации, который фиксирует важные для нас вещи. В процессе можно и нужно использовать AI
(2) когда план нас устраивает, то отдаем его LLM на реализацию
(3) запускаем параллельно несколько попыток реализации - мы выберем наиболее понравившуюся
(4) если все попытки кажутся неудачными - выкидываем изменения и дополняем план. План редактировать удобнее - т.к. там все изменения в одном месте, а не раскиданы по решению. Дальше, см пункт (2)
Команды разработчиков, которые успешно используют AI+Coding инструменты на больших проектах, тоже используют ту же парадигму:
(1) вместо ожидания идеального результата с первой попытки они работают с пространствами вероятностей - сначала прописывают все важное в плане, проверяют, а потом отдают на реализацию в коде.
(2) естественно, что бОльшую часть работы по написанию плана берет на себя AI
(3) при этом они не жалеют нервные клетки у AI и запускают сразу несколько вариантов одной и той же задачи, чтобы потом выбрать наилучший ответ.
Подробнее про процесс использования AI+Coding в проектах посложнее - написано в посте Как разрабатывать большие проекты с кучей зависимостей?
А вы уже пробовали подход с планами и множественными реализациями? Расскажете, как оно получилось?
Ваш, @llm_under_hood 🤗
Они говорят, что AI - это творческая и непредсказуемая штука:
Попробуйте несколько раз повторить один текстовый запрос, и вы увидите аналогичную ситуацию: идентичные вводные данные редко приводят к одинаковым результатам… Эта внутренняя случайность кардинально меняет нашу работу как UX-дизайнеров… Новые цели: курирование «пространств вероятностей» вместо построения идеальных путей
(цитата из внутренней переписки, переведена GPT-4.5)
И чтобы работать с пространствами вероятностей, дизайнеры сначала вместе с AI составляют планы и описания желаемых результатов. Они фиксируют в плане те вещи, которые должны четко быть отражены в результатах. А те моменты, где нужна непредсказуемость и вариативность - оставляют на “откуп” моделям.
Потом они запускают план несколько раз и выбирают понравившийся вариант. Если во всех реализациях схожие ошибки - они правят план и перезапускают.
Аналогично используют AI и копирайтеры (люди, которые пишут тексты). Сначала они вместе с AI собирают планы для написания текста (outlines), в которых прописывают важные факты, цитаты, структуру - все те вещи, которые нужно фиксировать. А потом отдают план LLM-ке на “разворачивание” в черновик текста. Причем, генерируют несколько вариантов текста, чтобы выбрать наиболее симпатичный для дальнейшей доводки.
Везде работает один и тот же принцип:
(1) сначала разрабатываем план реализации, который фиксирует важные для нас вещи. В процессе можно и нужно использовать AI
(2) когда план нас устраивает, то отдаем его LLM на реализацию
(3) запускаем параллельно несколько попыток реализации - мы выберем наиболее понравившуюся
(4) если все попытки кажутся неудачными - выкидываем изменения и дополняем план. План редактировать удобнее - т.к. там все изменения в одном месте, а не раскиданы по решению. Дальше, см пункт (2)
Команды разработчиков, которые успешно используют AI+Coding инструменты на больших проектах, тоже используют ту же парадигму:
(1) вместо ожидания идеального результата с первой попытки они работают с пространствами вероятностей - сначала прописывают все важное в плане, проверяют, а потом отдают на реализацию в коде.
(2) естественно, что бОльшую часть работы по написанию плана берет на себя AI
(3) при этом они не жалеют нервные клетки у AI и запускают сразу несколько вариантов одной и той же задачи, чтобы потом выбрать наилучший ответ.
Подробнее про процесс использования AI+Coding в проектах посложнее - написано в посте Как разрабатывать большие проекты с кучей зависимостей?
А вы уже пробовали подход с планами и множественными реализациями? Расскажете, как оно получилось?
Ваш, @llm_under_hood 🤗
❤41🔥20👍14💯3
Хорошая статья на тему AI+Coding
Аргументированная точка зрения от человека, который смотрит на LLM прагматично. Не как на откровение вайб-кодеров, но и не как на галлюцинирующий черный ящик. А как на полезный и уникальный инструмент, который уже меняет всю отрасль.
Обязательно читать: My AI Skeptic Friends Are All Nuts
Тон у статьи несколько провокационный, но с положениями о LLM - я в целом согласен.
Вот несколько понравившихся мне цитат про аргументы о AI+Coding:
(1) but the code is shitty, like that of a junior developer
Does an intern cost $20/month? Because that’s what Cursor.ai costs.
(2) but you have no idea what the code is
Are you a vibe coding Youtuber? Can you not read code? If so: astute point. Otherwise: what ... is wrong with you?
You’ve always been responsible for what you merge to main. You were five years go. And you are tomorrow, whether or not you use an LLM.
(3) but hallucination
If hallucination matters to you, your programming language has let you down.
Agents lint. They compile and run tests. If their LLM invents a new function signature, the agent sees the error. They feed it back to the LLM, which says “oh, right, I totally made that up” and then tries again.
(4) but it’s bad at rust
It’s hard to get a good toolchain for Brainfuck, too. Life’s tough in the aluminum siding business.
(5) but i’m tired of hearing about it
And here I rejoin your company. I read Simon Willison, and that’s all I really need. But all day, every day, a sizable chunk of the front page of HN is allocated to LLMs: incremental model updates, startups doing things with LLMs, LLM tutorials, screeds against LLMs. It’s annoying!
But AI is also incredibly — a word I use advisedly — important. It’s getting the same kind of attention that smart phones got in 2008, and not as much as the Internet got. That seems about right.
Ваш, @llm_under_hood 🤗
PS: Но при этом не забываем одну вещь. Весь этот AI+Coding пока хорошо работает для отдельных людей и небольших команд, стартапов. Стабильно и без перекосов масштабировать это на уровень компаний и больших проектов - мы все еще только учимся.
Аргументированная точка зрения от человека, который смотрит на LLM прагматично. Не как на откровение вайб-кодеров, но и не как на галлюцинирующий черный ящик. А как на полезный и уникальный инструмент, который уже меняет всю отрасль.
Обязательно читать: My AI Skeptic Friends Are All Nuts
Тон у статьи несколько провокационный, но с положениями о LLM - я в целом согласен.
Вот несколько понравившихся мне цитат про аргументы о AI+Coding:
(1) but the code is shitty, like that of a junior developer
Does an intern cost $20/month? Because that’s what Cursor.ai costs.
(2) but you have no idea what the code is
Are you a vibe coding Youtuber? Can you not read code? If so: astute point. Otherwise: what ... is wrong with you?
You’ve always been responsible for what you merge to main. You were five years go. And you are tomorrow, whether or not you use an LLM.
(3) but hallucination
If hallucination matters to you, your programming language has let you down.
Agents lint. They compile and run tests. If their LLM invents a new function signature, the agent sees the error. They feed it back to the LLM, which says “oh, right, I totally made that up” and then tries again.
(4) but it’s bad at rust
It’s hard to get a good toolchain for Brainfuck, too. Life’s tough in the aluminum siding business.
(5) but i’m tired of hearing about it
And here I rejoin your company. I read Simon Willison, and that’s all I really need. But all day, every day, a sizable chunk of the front page of HN is allocated to LLMs: incremental model updates, startups doing things with LLMs, LLM tutorials, screeds against LLMs. It’s annoying!
But AI is also incredibly — a word I use advisedly — important. It’s getting the same kind of attention that smart phones got in 2008, and not as much as the Internet got. That seems about right.
Ваш, @llm_under_hood 🤗
PS: Но при этом не забываем одну вещь. Весь этот AI+Coding пока хорошо работает для отдельных людей и небольших команд, стартапов. Стабильно и без перекосов масштабировать это на уровень компаний и больших проектов - мы все еще только учимся.
💯56❤17👍11🔥9🤔2🤯1