С приходом генеративных  текстовых моделей, таких как ChatGPT, мир разработки программного обеспечения сталкивается с новыми вызовами и возможностями. В этой статье мы рассматриваем семь основных рекомендаций для создания библиотек и фреймворков, которые максимально облегчат взаимодействие пользователей ваших продуктов с генеративными моделями и улучшат качество генерируемого кода. Применение этих рекомендаций поможет разработчикам адаптироваться к новому миру, где генеративные модели уже становятся неотъемлемой частью процесса разработки.

1. Соблюдать обратную совместимость Вообще это был хороший совет и без chat gpt, но теперь он актуален вдвойне. Если раньше в вашей библиотеке для указания того что хэндлеру надо обрабатывать функцию асихронно использовали декоратор @handle_async, а теперь вы решили просто передавать аргумент async=True, то будте готовы что ChatGPT с большой долей вероятности не прочтет ваши Release notes, а продолжит отвечать "по старому", опираясь на большое число использований на github и ответов на SO. Таким образом начальная проработка архитектуры библиотеки становится значительно более важной задачей, так как в будущем, нарушать обратную совместимость будет все сложнее и сложнее.

   

2. Использовать очевидный нейминг. Если в вашей нише есть несколько решений, постарайтесь сделать так, что бы нейминг как минимум основных методов и классов был одинаковым, так как ChatGPT сложно понять использование какой именно библиотеки разработчик от него ждет. Например, если есть общепринятый стандарт -  model.get_feature_importance()  для получения важности фич в некоторой модели, постарайтесь не городить огород из  model.features.importance()  или  model.feature_importances_  (пример CatBoost XGBost), может быть архитектурно такая структура данных и является более правильной, но тогда вы столкнетесь с тем, что Copilot будет выдавать неверный код, аналитикам, которые используют ваши решения.

3. Сделайте документацию более примероориентированной Очень подробно расписывать какие сущности есть в вашей библиотеки, что они делают и как взаимодействуют между собой, может быть очень полезно для опытных разработчиков, но нейросетям проще просмотреть тысячи примеров использования кода, что бы давать релевантные ответы

4. Добавьте тайпхинтинги Может для обычных программистов, указать что user_id во все методы вашей библиотеки нужно передовать как строку (как int/как объект UserID/как число с floating point)) где-то в начале документации было бы норм, но нейронкам, таким как Copilot итп(которые анализируют всю вашу среду разработки)  будет намного проще разобраться с кодом, если вы явно укажите user_id: str . Разумеется это актуально только для нестроготипизированных языков)

   

5. Больше текста, меньше картинок Нейросети на данном этапе развития не особо могут разбираться с картинками, поэтому в документации следует сделать опору на текст. Схемы и графики вставлять тоже можно, но сделайте так, что бы текст из них можно было копировать (то есть их нужно рисовать средствами HTML+CSS, а не вставлять картинки из фотошопа)

6. Обширный getting started  Если вы разрабатываете довольно нисшевое решение, и понимаете что крупные модели не смогут впитать в себя умение им пользоваться, сделайте подробный копифрендли getting started, что бы перед задаванием вопросов его можно было бы скормить нейросети самому. Новые текстовые модели (например Claude-instant-100k) могут воспринимать до 100к токенов (~100к слов) за запрос (для примера ВСЕ произведения, написанные А.С. Пушкиным содержат ~900к слов), так что ваш getting started модель спокойно скушает и сможет отвечать на некоторые вопросы разработчиков.

7. Документация на английском языке Вроде сейчас это уже норма, даже если вы пишете какой-то локальный продукт (например библиотеку для визуализации карт мос. метро), но все равно регулярно натыкаюсь на неанглийскую документацию. Модели намного охотнее кушают английский текст и тратя намного меньше токенов, и генерируют намного более релевантные ответы. К тому же английский язык очень хорошо подходит для написания технических текстов, благодаря прямому порядку слов, отсутствию падежей и родов.

   

Интересно ваше мнение по этому вопросу, насколько важно делать "GPT-ориентированные интерфейсы?