Промт-инжиниринг: ерунда или новая грамотность?

Несмотря на то, что ИИ уже прочно часть моей работы и жизни, я все истории про промт-инженеров и сложности составления промтов воспринимала больше как хайп и юмор.

Почему?

1️⃣ Для меня постановка задачи к команде разработки и к ИИ про одно и то же. В каждом случае вводишь в контекст, даёшь все вводные, объясняешь, что стоит использовать и к чему нужно прийти на выходе. Более того, это основа любого общения, где задача быть понятым. То есть в отношениях с родными, друзьями и всем окружающим миром.

Даже особенности работы с ИИ всё же есть, связанные с галлюцинациями, напоминают обычные правила коммуникации. Например:
— «Если не знаешь, не придумывай, а скажи, что не знаешь».
— «Если вводных недостаточно, задай вопросы».
— «Не отходи от изначальной темы».
— «Опирайся на проверенные источники».

2️⃣ Копаясь в базах данных промтов, я скорее видела, что просто не всем доступно в обычной жизни искусство разъясняться. А у аналитиков это уже профессиональное: если не хочешь результат “ХЗ”, то делай нормально ТЗ.

3️⃣ Часто к ИИ мы обращаемся не за уникальной сложной работой, а за рутиной. И там даже модели двухгодичной давности, бесплатные, справляются неплохо, с промтами, которые «ну такое себе». Отлично это демонстрирует доклад Алишера Умарова А последние модели уже и вовсе предугадывают контекст и требуют меньше данных на входе.

Между тем недавно я стала участником конкурса от Systems Education #продолжи_мысль_SE, и там многие писали именно про промты. Вначале я решила, что это не стоит моего внимания, но одновременно с конкурсом произошёл забавный случай:

Идёт обсуждение внедрения ИИ в одну из систем. И представители команды внедрения ИИ говорят: «Вам нужно будет нанять промт-инженера!». Мой мир переворачивается: почему серьёзные компании тратят деньги на «ерунду» в виде промт-инженеров?

Пришлось возвращаться к постам и осмыслять. Больше всего меня зацепил пост «Ментальная карта промтов для аналитика», как и сам канал Елены посвященный во многом промтам.

Сначала находила подтверждения скепсису, но чем глубже читала, тем яснее видела системность карты. Через некоторое время я поняла, почему

«ментальная карта промтов это способ мыслить, делегировать и усиливаться как аналитик».

«Как аналитик» здесь очень важно. Промты это возможность с помощью чужого опыта получить классное решение на рутинную и не очень задачу.

Карта получилась очень объёмная, но не перегруженная, как один из самых известных источников промтов.

Практикующему системному аналитику с помощью карты можно ускорить время не только за счёт использования ИИ, но и за счёт подготовки задач для ИИ. По факту это всесторонний чек-лист аналитика.

Для начинающих специалистов и менторов интерес могут представлять и сами промты. Некоторые из них можно использовать для обучения джунов: чтобы они сами пробовали по ним делать задачу и понимали, на что опираться.

А ещё такая карта подойдёт тем, кто всё же не может совладать с искусством промт-инжиниринга. По карте легко изучать, осмыслять и пробовать!

Нашлось кое-что полезное и для меня в разделе про сам промт-инжиниринг. А именно несколько интересных промтов, как прокачать ответы и уменьшить галлюцинации.

Из минусов: большинство примеров промтов всё же на базовый и стандартный уровень. У моего супруга такой уровень SQL на работе требуется, что предложенные промты ему точно не помогут. Но это уже про особенности конкретной работы аналитиком, чем про карту.
Ещё момент: карту просто так не получишь. Я такое ограничение не одобряю, хотя оно и стимулирует не просто сохранить пост, а действительно осмысленно получить карту и потом её использовать.

Изменилось ли моё отношение к промт-инжинирингу после поста с картой? И да, и нет, но точно стало теплее.

А ещё пост навёл меня на мысль: может оказаться, что обучение промт-инжинирингу поможет не только в работе с ИИ? Может, всё больше людей сможет лучше изъясняться друг с другом и в обычной жизни? Или наоборот, мы всё заменим ИИ, например, как заменили поздравления и нецензурные письма коллегам.)

Напоминаю, что уже завтра стартует в Самаре конференция аналитиков Поволжья SAMBA_CONF

Завтра онлайн день, а в воскресенье будет оффлайн!

Жду с нетерпением, так давно такого не было в Самаре)

Я для участников подготовила воркшоп по EventStorming, сначала хотела с другой темой выступить, но так соскучилась сама по ES в живую, что решила все же пойти по уже знакомому пути.

Промокод на скидку 20% от меня

@ANALYTICAGAIN

Плагины для Visual Studio Code для описания OpenAPI

Вообще описание OpenAPI-спецификации простая рутинная работа, которую можно поручать новичкам и где-то ИИ. Но я люблю иногда такие задачки оставлять на себе: когда постоянно работаешь с хаосом, рутина успокаивает и дает положительное подкрепление выполненной работы, среди долгоиграющих задач.

Но облегчать себе жизнь всё же нужно. И вот мой набор расширений для VS Code которые помогают в этом:

Редактор, проверка и валидация

🔧 YAML от RedHat🔧 Кажется, он всегда предустановлен. Но версия 1.18 косячная, лучше откатиться до 1.17. Это и редактор, и автодополнение, и переходы по $ref (в том числе между файлами). В целом может быть достаточно, если нет возможности ставить сторонние расширения.

🔧 OpenAPI (Swagger) Editor🔧 Есть шаблоны для новых документов, удобный редактор, очень нравится возможность ходить по дереву описанного документа.

🔧 Stoplight Spectral🔧 Линтер с готовыми правилами для OpenAPI. Фишка, что можно добавлять свои правила. Но пока я ленивая какашка, и не добавила в правила договорённостей в команде. Поэтому он меня часто раздражает, из-за своих правил. Но мы с коллегой договорились довести его до ума и встроить в процесс CI/CD (расскажу о результатах отдельно).

Предпросмотр

👀 Swagger Viewer 👀 Классика. Показывает, что же вы там понаписали и собирается ли это вообще. В последних версиях появился поиск — очень удобно.

Тестирование

🧪 Thunder Client 🧪 Простенький аналог Postman. Для большинства REST-задач мне хватает, плюс удобно, что всё прямо внутри VS Code.

Ну конечно еще ряд расширений для Git. Но там стандартный набор.

Вот такой нехитрый набор, который делает простую работу ещё проще. Рекомендую.

Расширения с ИИ для работы с OpenAPI-спецификацией ещё не искала, поэтому если знаете хорошие, делитесь!

👀Не люблю работать с сеньорами

Самые сложные случаи работы в команде, где возникало больше всего проблем, были связаны с работой с сеньорами. Мне везло работать с классными, опытными специалистами, с которыми мы реализовывали различные фичи. Но что отличало большинство из них? Огромное количество опыта, знакомство с типовыми кейсами, уверенность в том, как должно быть.

Почему же возникали сложности?

1️⃣ Если сеньор видел, что где-то можно сделать лучше, он это делал, не предупредив и не выяснив, почему было выбрано другое решение.
К чему это приводило: переставало работать то, что уже давно работало, или происходили большие расхождения с требованиями.

2️⃣Свои гениальные решения сеньоры редко кому-то объясняют.
К чему это приводит: сборная солянка решений для однотипных задач. Команда не понимает, почему это решение лучше, обмен знаниями не происходит, рост затрудняется.

3️⃣Сеньоры часто пренебрегают чужим опытом. Они уже многое видели, и если чего-то не знают, значит, это ерунда.
К чему это приводит: к часовым созвонам и подготовке доказательств, почему твое решение имеет право на жизнь. Если это сочетать с пунктом 2, такие обсуждения превращаются в настоящие детективные расследования.

4️⃣Склонность к микроменеджменту.
К чему это приводило: меня всегда бесили те, кто из отпуска писали, что точка в ответе на ошибку важна. Лучше бы вы так делились своим опытом.

5️⃣Сеньоры не дают раскрыться другим специалистам, особенно джунам. Это такая айти-дедовщина.
К чему это приводит: часть новичков уходит, а другие становятся равнодушными. Ошибки начинают копиться, потому что всегда есть сеньор, который всё равно "достанет" тебя, как бы хорошо ты не сделал.

6️⃣Некоторые сеньоры, повидавшие "Г…", становятся равнодушными и токсичными. Часто они работают спустя рукава, а прикрываются нападками на других.
Помните мой пост про ретроспективу? Так вот, главный токсик был сеньором.

🛠
Конечно, не все сеньоры такие. И здесь у меня есть совет только самой себе: когда дорасту до нужного уровня, не забывать, что сила в командной работе. Никогда не забывать о важности делиться своими знаниями и объяснять свои решения. Оставаться гибкой к новым технологиям, мнениям и людям. Открытые диалоги — сила вне зависимости от опыта. И да, учиться нужно будет всегда.

А как у вас обстоят дела в работе с сеньорами?

#СистемныйАнализ #КарьеравИТ #сеньор

Я честно ожидала более живого обсуждения под последним постом: не могу понять сложно или не интересно и все уже давно на gRPC?

Но раз от вас интересных примеров в комментариях не прилетело, вот еще несколько вариантов, когда у DELETE есть тело запроса.

1) Указание невалидного токена в теле в Oauth2. Другой пример от них же пример с API key. API Elastic Search вообще для меня находка для изучения. Много спорного, но интересно.

DELETE /_security/oauth2/token
{
  "token" : "токен который нужно отозвать"
}

2) Частичное удаление из коллекции есть ArangoDB и WB

3) Массовые операции, в необычной реализации есть у Яндекса.

#интеграции #RESTAPI #OPENAPI

В прошлом сентябре я подала заявку в программу Mentor in Tech

Это программа БЕСПЛАТНОГО наставничества для ЖЕНЩИН от сообщества Women in Tech. Наставниками могут стать все желающие с опытом 3+ лет в направлениях, объявленных на сайте. А вот участие в роли менти ориентировано только на женщин.

Механика простая: и наставники, и менти подают заявки через телеграм-бот, где подробно рассказывают о себе, своём опыте и запросах. Затем по совпадениям формируются пары. В течение 3–4 месяцев они встречаются минимум трижды, чтобы разбирать запросы менти.

До прошлого года я никогда не задумывалась и не осмысляла все нюансы «свободного» наставничества. Поэтому программа стала для меня открытием именно в плане обучения менторов.

Общение с менти (у меня их было трое) тоже оказалось крайне полезным: я росла как специалист и расширяла свои границы. Хотя сегодня оцениваю себя как ментора в этой программе скорее средне. Но это как говориться совсем другая история.

Главное, что я вынесла с программы: «В менторстве всегда участвуют два взрослых человека». Простая мысль, но очень важная для обеих сторон.

От души рекомендую программу и менторам, и тем кому нужна помощь в наставничестве.

Я уже подала заявку! Правда, в этот раз, в роли менти.

#КарьеравИТ #ментор #наставник

ЛИНТЕР придёт и покажет, кто плохо себя вёл

В постах я пару раз упоминала линтер, и у многих возникал вопрос: что это вообще за чудо?

Так называют небольшие утилиты, которые анализируют код ещё до компиляции и ищет ошибки, проблемы и подозрительные конструкции. Внутри они содержат набор правил, которым должен соответствовать код.

Я, как аналитик, чаще всего сталкиваюсь с линтерами при работе с OpenAPI и AsyncAPI спеками. Ещё один линтер был по моим требованиям написан для запросов к нашей БД.

Во многих IDE есть встроенные линтеры, но их можно расширять и добавлять собственные правила. Последнее позволяет автоматизировать ревью в случаях, когда у вас есть внутренние правила разработки. Очень помогают экономить время.

А ещё линтер не устаёт. В отличие от тимлида, он будет ворчать на твой код даже в 3 часа ночи.

#автоматизация #глоссарий

Безумные выходные: Как из Event Storming рождается System Design

После майского воркшопа по Event Storming мне дали обратную связь: «Классно, но что дальше? Как вообще Event Storming соединять с архитектурой?»

Было и ещё одно замечание: "кейс слишком узкоспециализированный и простой". Я долго думала над выбором примера, и он был таким осознанно. Но поставив себя на место участников, поняла: да, хочется кейсов амбициозных, таких, от которых сразу мысль: «Вау!»

Сложив всё это вместе, я пошла ныть закидывать идеи Андрею Буракову.

Так родились безумные выходные: Event Storming + System Design Club, где будем разбирать процесс выпуска пластиковых карт. Про сам клуб я уже рассказывала здесь.

Для меня, как ведущей, это вызов: кейс не из моей профессиональной сферы, в рамках МК нужно строже следить, чтобы результат перетек к следующий этап. Сейчас активно меняю механику, чтобы команды не ушли слишком глубоко в дебри.

С другой стороны, для участников задача станет проще: понятна цель на Event Storming, а агрегаты на следующем этапе будут восприниматься легче. И может, наконец-то, получится наглядно донести что это такое.

Формат тестовый, и, возможно, повторений не будет.

👉 Поэтому успевайте: 27–28 сентября с 10 до 14 мск.