Спасибо за вопрос! Пока нет, имеет смысл, когда наберётся достаточно реальной истории, будет понятно, есть ли смысл оптимизировать и что именно. Стартово не рассматривал ещё и потому, что для агента-консультанта важно отвечать не шаблонно, а подстраиваться под ситуацию и стиль конкретного пользователя.
Плюс в нашем случае все вопросы контекстно-зависимы и в базе знаний информация может меняться частенько. И еще есть нюанс, связанный с тем, что в таком кэше надо быть уверенным, что туда не закрались ошибочные ответы ) Поэтому кажется проще подготовить выверенный FAQ, сделать его частью базы знаний, обновлять синхронно с основными документами и уже его использовать как альтернативу кэшу по истории диалога.
Где же там речь про стажера с LLM. Явно написано, что аналитик с тех бэкграундом.
Уточню в этом проекте у руля вместе с ИИ стоит специалист с техническим бэкграундом, но который последние 10 лет выступал в роли бизнес и системного аналитика в этом проекте.
Продавцы счастья по формуле "LLM и стажер заменили N разработчиков"
Где Вы увидели такое заявление - мне не понятно. Наоборот речь не про замену, а про сильный инструмент в умелых руках разработчиков. Пользоваться им или нет дело каждого.
Статья не про веру и попытку обратить в веру кого-то ) А про то где LLM приносит пользу и каким образом.
Тем кто пользуется не надо "слепо" верить или ждать доказательств от кого-то. Потому что они попробовали, научились, пользуются и повышают свои и проектную эффективность.
Человек тоже решает крупную задачу по частям. Правит, запускает тесты, смотрит результат, проверяет руками, отладкой пользуется. Это все воспроизводит и кодовый агент под контролем человека.
Уступает, так как в нем это не встроено в процесс работы из коробки, как это сделано в Kiro и Qoder. Но на самом деле весь план генерит языковая модель, и никто не мешает в Cursor генерить план самим ) Хотя Kiro и Qoder это шаг вперед к упорядочеванию процесса.
Вы имеете ввиду, если одновременно ведется развитие проекта, затрагивающего общие части?
И кстати, как тестируете? По опыту ai очень хреново умеет selenium/playwright/прочие e2e. Мы пока думали на cucumber+gherkin подвесить, там хотя бы текст
Пока используем подход написания unit тестов и e2e интеграционных тестов. Ограничиваем кол-во тестов, буквально пару e2e. По поводу "хреново умеет" - зависит от модели и наличия примеров (можно использоваться Docs или MCP, например, context7)
Кстати, а что ваш этот "проект" собственно делает? Рандомные фотки котиков раз в день пользователю отгружает? Из Google Maps адреса заведений где тыквенный латте подают тянет? Намекните хотя бы ))
Когда будет анонс выступления по этой теме я вышлю сюда вам ссылку. Посмотрите в записи или онлайн приходите. Всегда интересно с оппонентами подхода пообщаться. Если, конечно, вы будете сохранять уважение к мнению других специалистов.
Проект решает задачу автоматизации бизнес процессов работы организации и оказания услуг клиентам. Это большая крупная система.
Пока кто-то соперничает с ИИ, пытаясь доказать что ИИ глуп. Другие применяют ИИ, таким какой он есть на данный момент. Учатся с ним правильно работать. Применяют его там, где он поднимает именно их эффективность. А где они лучше - не применяют. Ибо зачем.
Т.е. мы говорим о том, что большинство проектов построены довольно таки сложно, запутанно. Разбираться в них даже людям-новичкам тяжело. Многие проекты заведены в точку Ж и т.п. Источник правды, почему сделано именно так, а не по другому давно потерян. Используются самописные фреймворки и инструментарии, вместо общепринятых опенсорсных и т.п. Правильно?
Если так, то конечно и ИИ будет это также тяжело и трудно. Но такие проекты с большим тех долгом и людьми то тянутся со скрипом.
По сути как и раньше, выхода два - снижаем техдолг, рефакторим или пересоздание с чистого листа. И в том и в другом случае если мы хотим работать с ИИ надо заботиться о создании хорошей базы знаний/графа знаний, чтобы ии мог быстро находить нужный контекст.
Что-то в консерватории не то. Изобретать Вайбить очередной велосипед. После чего нейронки на них обучатся получше, велосипедов станет побольше. Есть сходимость у этого процесса и куда?
Если случай неуникальный, то зачем ещё один велосипед?
Речь не про копипасту кода или разработку под копирку велосипеда. А речь про тип разрабатываемого ПО, большая часть ПО не является чем-то уникальным с точки зрения кода. Учетные системы, автоматизация бизнес процессов, erp, порталы, мобильные приложения и т.д. и т.п. - все в общем и целом типовое, отсюда и тако изобилие фреймворков, потому что все решают похожие задачи. И вот для такого рода "не уникальных" приложений ИИ получила хорошую базу для обучения.
А если мы заводим речь о чем-то выходящем из этого круга, то базы у ИИ намного меньше, чтобы выдавать хороший код.
А вы можете продемонстрировать эти способы? Ну, например, примитивное - расчёт кулачковых механизмов. Они плоские, САПРы ещё на перфокартах существовали. Учебников и справочников в интернете дофига.
Ну прям совсем делать-делать не надо, просто покажите, пожалуйста, что куда запихнуть и какой промт, на ваш взгляд нужен? Методика же у вас рабочая?
Я не эксперт в расчетах кулачковых механизмов - поэтому не смогу продемонстрировать применительно к этой задаче. Но в общем если брать описанный подход, то я бы на этапе проектирования (создания vision):
вместе с ИИ под задачу провел поиск документации, статей, описывающих алгоритмы вычисления, мб библиотек, решающих такие задачи или даже опенсорс проектов - с этим хорошо справляется deep research (лучший у openai, на мой взгляд)
далее тщательно проработал бы алгоритм
сформировал базу рефернсной документации, на которую бы ссылались как пример написания кода
сформировал правила conventions, в которых бы явно указывал брать примеры из этой доки
Опять как то странно все, у вас человек на проект приходит, осваивается, через пару недель уже можно задачи давать, зависит от уровня, какие именно, смотря на сколько вник и какой потанцевал.
И все это время можно потратить не для того, чтобы одного спеца погружать. А создать хорошую базу знаний и контекст проекта удобный для восприятия ИИ.
ИИ каждый раз как новый лист. Только для его работы нужна куча промфтов. Которые не всегда дадут один и тот же ответ.
Суть подхода, как раз в том, чтобы контекст не каждый раз создавать. А фиксировать его в файлах, правилах. Тогда это делается ровно также разово, как и погружении нового спеца в проект.
Абсолютно точно! Визуализация сильная сторона. Несколько диаграмм привел в статье! Моя любимая для понимания логики - диаграмма последовательности. На ней и логика и модульность и слои
отдельные куски кода можем и показать, всю кодовую базу коммерческого проекта понятное дело никто не отдаст но вопрос. а зачем смотреть на код? ИИ может генерить код, так как мы ее проинструктируем это делать. но важнее не то, как этот код красивее для людей, а как этот код удобнее для написания и доработки самой ллм.
Спасибо за вопрос! Пока нет, имеет смысл, когда наберётся достаточно реальной истории, будет понятно, есть ли смысл оптимизировать и что именно. Стартово не рассматривал ещё и потому, что для агента-консультанта важно отвечать не шаблонно, а подстраиваться под ситуацию и стиль конкретного пользователя.
Плюс в нашем случае все вопросы контекстно-зависимы и в базе знаний информация может меняться частенько. И еще есть нюанс, связанный с тем, что в таком кэше надо быть уверенным, что туда не закрались ошибочные ответы ) Поэтому кажется проще подготовить выверенный FAQ, сделать его частью базы знаний, обновлять синхронно с основными документами и уже его использовать как альтернативу кэшу по истории диалога.
Супер! Очень рад за успехи! Делитесь, пожалуйста, тут или в нашем телеграмме aidialogs
Согласен. Будем набираться опыта, будем делиться им. Пока не на всех этапах и масштабах накоплены бест практики
Где же там речь про стажера с LLM. Явно написано, что аналитик с тех бэкграундом.
Уточню в этом проекте у руля вместе с ИИ стоит специалист с техническим бэкграундом, но который последние 10 лет выступал в роли бизнес и системного аналитика в этом проекте.
Где Вы увидели такое заявление - мне не понятно. Наоборот речь не про замену, а про сильный инструмент в умелых руках разработчиков. Пользоваться им или нет дело каждого.
Пусть не ИИ, а LLM - ок.
Статья не про веру и попытку обратить в веру кого-то ) А про то где LLM приносит пользу и каким образом.
Тем кто пользуется не надо "слепо" верить или ждать доказательств от кого-то. Потому что они попробовали, научились, пользуются и повышают свои и проектную эффективность.
Так мы и ведем речь про работу с ИИ
Человек тоже решает крупную задачу по частям. Правит, запускает тесты, смотрит результат, проверяет руками, отладкой пользуется. Это все воспроизводит и кодовый агент под контролем человека.
Спасибо! Все так.
Уступает, так как в нем это не встроено в процесс работы из коробки, как это сделано в Kiro и Qoder. Но на самом деле весь план генерит языковая модель, и никто не мешает в Cursor генерить план самим ) Хотя Kiro и Qoder это шаг вперед к упорядочеванию процесса.
А кто "он", какой процесс работы вы имеете ввиду?
Суть описанного подхода, как раз в том, чтобы решить эту проблему.
Спасибо. Пробуйте, ждем обратной связи )
Вы имеете ввиду, если одновременно ведется развитие проекта, затрагивающего общие части?
Пока используем подход написания unit тестов и e2e интеграционных тестов. Ограничиваем кол-во тестов, буквально пару e2e. По поводу "хреново умеет" - зависит от модели и наличия примеров (можно использоваться Docs или MCP, например, context7)
Когда будет анонс выступления по этой теме я вышлю сюда вам ссылку. Посмотрите в записи или онлайн приходите. Всегда интересно с оппонентами подхода пообщаться. Если, конечно, вы будете сохранять уважение к мнению других специалистов.
Проект решает задачу автоматизации бизнес процессов работы организации и оказания услуг клиентам. Это большая крупная система.
Пока кто-то соперничает с ИИ, пытаясь доказать что ИИ глуп. Другие применяют ИИ, таким какой он есть на данный момент. Учатся с ним правильно работать. Применяют его там, где он поднимает именно их эффективность. А где они лучше - не применяют. Ибо зачем.
Т.е. мы говорим о том, что большинство проектов построены довольно таки сложно, запутанно. Разбираться в них даже людям-новичкам тяжело. Многие проекты заведены в точку Ж и т.п. Источник правды, почему сделано именно так, а не по другому давно потерян. Используются самописные фреймворки и инструментарии, вместо общепринятых опенсорсных и т.п. Правильно?
Если так, то конечно и ИИ будет это также тяжело и трудно. Но такие проекты с большим тех долгом и людьми то тянутся со скрипом.
По сути как и раньше, выхода два - снижаем техдолг, рефакторим или пересоздание с чистого листа. И в том и в другом случае если мы хотим работать с ИИ надо заботиться о создании хорошей базы знаний/графа знаний, чтобы ии мог быстро находить нужный контекст.
Речь не про копипасту кода или разработку под копирку велосипеда. А речь про тип разрабатываемого ПО, большая часть ПО не является чем-то уникальным с точки зрения кода. Учетные системы, автоматизация бизнес процессов, erp, порталы, мобильные приложения и т.д. и т.п. - все в общем и целом типовое, отсюда и тако изобилие фреймворков, потому что все решают похожие задачи. И вот для такого рода "не уникальных" приложений ИИ получила хорошую базу для обучения.
А если мы заводим речь о чем-то выходящем из этого круга, то базы у ИИ намного меньше, чтобы выдавать хороший код.
Я не эксперт в расчетах кулачковых механизмов - поэтому не смогу продемонстрировать применительно к этой задаче. Но в общем если брать описанный подход, то я бы на этапе проектирования (создания vision):
вместе с ИИ под задачу провел поиск документации, статей, описывающих алгоритмы вычисления, мб библиотек, решающих такие задачи или даже опенсорс проектов - с этим хорошо справляется deep research (лучший у openai, на мой взгляд)
далее тщательно проработал бы алгоритм
сформировал базу рефернсной документации, на которую бы ссылались как пример написания кода
сформировал правила conventions, в которых бы явно указывал брать примеры из этой доки
дальше план разработки и все по методике
Именно, в том же Cursor довольно неплохо выстроена система RAG для сбора подходящего контекста для решения задачи
И все это время можно потратить не для того, чтобы одного спеца погружать. А создать хорошую базу знаний и контекст проекта удобный для восприятия ИИ.
Суть подхода, как раз в том, чтобы контекст не каждый раз создавать. А фиксировать его в файлах, правилах. Тогда это делается ровно также разово, как и погружении нового спеца в проект.
Абсолютно точно! Визуализация сильная сторона. Несколько диаграмм привел в статье! Моя любимая для понимания логики - диаграмма последовательности. На ней и логика и модульность и слои
Спасибо! Пользуйтесь ) Делитесь обратной связью и результатами здесь или в нашем ТГ канале
отдельные куски кода можем и показать, всю кодовую базу коммерческого проекта понятное дело никто не отдаст
но вопрос. а зачем смотреть на код? ИИ может генерить код, так как мы ее проинструктируем это делать. но важнее не то, как этот код красивее для людей, а как этот код удобнее для написания и доработки самой ллм.
Спасибо. Рад, что понравилось. Пользуйтесь подходом, делитесь результатами. Буду очень рад обратной связи