ИИ-инструменты уже активно вошли в процессы разработки софта, и любое упоминание об этом, как правило, сопровождается дискуссией, нередко переходящей в спор.

Потому я хотел бы начать публикации в нашем канале с попытки некоторого "околонаучного" материала, который я назвал "Оценка эффективности применения AI в SDLC". (Если подзабыли, этой аббревиатурой - SDLC - обозначают жизненный цикл разработки программного обеспечения).

Я назову условно инструмент, который собираюсь использовать как разработчик, "A-tool" и попытаюсь разработать структурированный подход к оценке эффективности его применения.

1. Определить критерии оценки.
Прежде чем приступить к измерениям, определите четкие критерии того, что вы считаете «эффективным».
Они могут включать в себя:
• Время разработки: время, необходимое для выполнения определенных задач или проектов до и после использования A-tool.
• Показатели качества: количество зарегистрированных ошибок или дефектов, серьезность проблем и оценки качества кода.
• Продуктивность: функции или пользовательские истории, реализованные за спринт или фиксированный период времени.
• Удовлетворенность команды: как команда разработчиков относится к использованию инструмента, измеряемая с помощью опросов или интервью.
• Затраты: как прямые затраты (например, лицензия на A-tool), так и косвенные затраты (например, время обучения, усилия по интеграции).

2. Измерение базовой линии
Соберите данные по определенным критериям, прежде чем интегрировать A-tool в свой рабочий процесс. Это служит вашими контрольными данными для сравнения.

3. Интеграция и обучение
Интегрируйте A-tool в свой процесс разработки и убедитесь, что ваша команда достаточно обучена его использованию. Задокументируйте любые первоначальные проблемы или наблюдения.

4. Сбор данных после интеграции
После разумного периода использования A-tool соберите те же показатели, что и для базового измерения. Убедитесь, что сравнение справедливо, сохраняя другие переменные как можно более постоянными.

5. Анализ
Проанализируйте собранные данные, чтобы оценить влияние A-tool:
• Время разработки: сравните время, необходимое для выполнения задач или проектов до и после использования A-tool. Сокращение времени может указывать на повышение эффективности.

Сокращение времени"="Базовое время−Время после интеграцииБазовое время×100%Сокращение времени"="Базовое времяБазовое время — время после интеграции×100%

• Показатели качества: анализируйте изменения количества и серьезности ошибок или проблем. Улучшение качества кода или уменьшение количества дефектов предполагает эффективность.
• Продуктивность: оцените изменение количества функций или пользовательских историй, выполненных за одинаковые сроки.
• Удовлетворенность команды: анализируйте результаты опросов или отзывы, чтобы оценить адаптацию и удовлетворенность команды A-tool.
• Анализ затрат: Учитывайте как прямые, так и косвенные затраты до и после интеграции A-tool. Рассчитайте рентабельность инвестиций (ROI), если применимо.

рентабельность инвестиций"="Преимущества−РасходыРасходы×100%рентабельность инвестиций"="РасходыПреимущества − Затраты×100%

6. Выводы и принятие решений
На основании анализа сделать выводы об эффективности А-инструмента:
• Положительное влияние: если вы заметите значительное улучшение эффективности, качества и удовлетворенности команды управляемыми затратами, A-tool можно считать эффективным.
• Негативное влияние: если инструмент А приводит к увеличению затрат, снижению качества или неудовлетворенности команды без существенных выгод, его принятие может быть пересмотрено.

7. Непрерывный мониторинг
Даже после первоначальной оценки продолжайте следить за эффективностью А-инструмента. Среда разработки программного обеспечения и динамика команды могут меняться, что со временем может повлиять на полезность инструмента.

Такой структурированный подход позволяет провести всестороннюю оценку влияния A-tool на ваш процесс разработки, помогая вам принять обоснованное решение о его дальнейшем использовании.

Кстати, эта разработка подхода к оценке применения A-tool в разработке ПО заняла у меня пять минут. Я просто попросил сделать это GPT-4.

См. сюда: https://chat.openai.com/share/67e2d470-25a5-486e-b38d-861465419c17

ну все написано для "коня (проекта) в сферическом вакууме" и это красиво, звучит умно как и сотни книг написанных по сбору метрик.
При попытке перейти к реальному коню (проекту) возникает проблема приведения полученных данных к единому базису, те к чему то что позволит сравнить два проекта (коней) которые принципиально разные и по сложности функционала и по платформе реализации и по квалификации команды его реализующего и т.д. и т.п.

ну и что от одного проекта будем умножать\делить\вычитать\складывать от второго проекта если базис проектов разный ?
Ну умножим\поделим\вычтем\сложим и получим какие то циферки. Вопрос - а что эти цифры нам дадут в случае разных проектов (см.выше первые пришедшие на ум возможные отличия) ?
На мой взгляд прежде чем писать красивый, большой и трудно запоминаемый список чего будем мерять, ChatGPT должен был сформулировать правила выбора проектов+исполнителей для сравниваемых проектов

На пути к безопасным инструментам на основе ИИ. Разработчикам на заметку.

Наконец-то действительно ответственный ИИ. Чат-бот GOODY-2 «создан с учетом передовых этических принципов нового поколения»: он дает максимально безопасные и этичные ответы. То есть бесполезные. Например:

— Как сварить яйца?
— При варке используются высокие температуры, это может привести к ожогам или пожару.

Это будущее.

Рассказываем, как создать чат-бота, который может отвечать на вопросы на основе корпоративных данных, используя подходы RAG (Retrieval-Augmented Generation) и LangChain: https://bit.ly/3UBu0VS

RAG — это метод, который сочетает в себе извлечение текста и его генерацию, позволяя чат-боту выбирать релевантные документы из большого корпуса данных и использовать их для генерации ответов.

А вы применяли RAG в своих разработках? Делитесь своими кейсами в комментариях!

В середине февраля Google выпустила для внутреннего использования модель Goose на базе LLM Gemini для помощи программистам в написании кода. Goose был получен при помощи дообучения LLM Gemini с использованием датасета, созданного на основе внутреннего репозитария кода.

Мы погуглили соцсети, но впечатляющих подробностей пока так и не увидели.
Судя по постам в Twitter модель имеет контекстное окно в 28к токенов, т.е. порядка 5000 строк кода, умеет работать со специфичными для Гугла технологиями, писать код на основе запросов на естественном языке. Похоже что компания рассматривает свой Copilot как одно из средств сокращения расходов.

Вот мнение не последних членов сообщества