Вчера рассказал про формочку для хэлсчека, а сегодня вот Женя @that_ai_guy с утра сделал ПР, в котором сделал UX как про! Так что теперь эта формочка еще и с охуенным UXом!

🤖 Semantic Kernel, часть 1: если ты хочешь написать мини-агента за две строчки кода.

У нас сейчас есть задачка — при открытии стран надо модифицировать несколько проектов: добавить свитч-кейсы, прописать новые значения в нужных местах и сделать ПРы.

Идея – эту задачку выпнуть как-то на LLM. Звучит просто, но как представляешь себе реализацию — сразу ощущение надвигающейся геморройной жести с ифчиками и парсингом ответов от LLM.

А хочется, чтобы LLM сам решал, что делать: прочитать файл, создать ветку, закоммитить изменения, открыть PR. Но в голове сразу картинка: парсишь ответ от LLM, руками вызываешь нужную библиотеку, обрабатываешь результат, снова что-то парсишь. Руки опускались ещё на этапе проектирования.

А потом я наткнулся на Semantic Kernel. Про который много слышал, но не понимал что это.

Так вот! Фактически – это мини-агент который можно дергать через бэк. Типа мини-курсор или мини-копайлот.

Идея простая:

1️⃣ Ты описываешь инструменты — обычные C# методы, которые дергают апишки (к примеру гитхабовские) с атрибутом [KernelFunction] и Description.

2️⃣ SK подпихивает эти методы LLMке. Через рефлексию и вот это все.

3️⃣ Дальше запускается маленький агентный цикл: SK делает вызов, возвращает результат обратно в контекст — и так по кругу пока задача не решена.

И все это за вас! Написать агентный цикл в целом тот еще гемор, а тут все готово.

Вот так регаем инструмент:

[KernelFunction, Description("Создаёт pull request в репозитории")]
public async Task<string> CreatePullRequest(
    [Description("Владелец репозитория")] string owner,
    [Description("Название репозитория")] string repo,
    [Description("Заголовок pull request")] string title,
    [Description("Описание pull request")] string body,
    [Description("Ветка с изменениями")] string headBranch,
    [Description("Целевая ветка")] string baseBranch = "main")
{
    var pr = await _client.PullRequest.Create(owner, repo,
        new NewPullRequest(title, headBranch, baseBranch) { Body = body });
    return $"PR создан: {pr.HtmlUrl}";
}

Вот так вызываем промпт:

var kernel = Kernel.CreateBuilder()
    .AddOpenAIChatCompletion("gpt-4o", openAiKey)
    .Build();

kernel.Plugins.AddFromObject(new GitHubPlugin(githubToken), "GitHub");

var settings = new OpenAIPromptExecutionSettings
{
    FunctionChoiceBehavior = FunctionChoiceBehavior.Auto()
};

Дальше говоришь агенту: «отредактируй README.md в owner/repo, добавь раздел Installation, создай PR» — и он сам читает файл, создаёт ветку, коммитит изменения и открывает PR. Без единого ифчика с твоей стороны.

Вот тут можете посмотреть как это все работает: https://github.com/Undermove/csharpshortpostsexamples/tree/main/SemanticKernelExample.

🅰️ Итого: Если у вас есть ощущение, что вы хотите на бэке иметь под некоторые задачи мини-агента, который бы взаимодействовал с апишками, то попробуйте Semantic Kernel в качестве обертки.

Хочу показать разницу. Которую я сам не понимал: Function Calling у OpenAI (и других) есть и без SK. Но вот агентный цикл — то есть “вызвал тул, получил результат, спросил LLM снова, повторить“ — ты пишешь руками.

Просто для сравнения:

Без SK:

var messages = new List<ChatMessage> { new("user", prompt) };

while (true)
{
    var response = await openAiClient.Chat.CreateAsync(
        new() { Model = "gpt-4o", Messages = messages, Tools = tools });

    if (response.FinishReason == "stop") break; // задача решена

    // достаём все запрошенные тул-вызовы
    foreach (var toolCall in response.ToolCalls)
    {
        var result = toolCall.Name switch
        {
            "CreatePullRequest" => await github.CreatePR(toolCall.Args),
            "ReadFile"          => await github.ReadFile(toolCall.Args),
            "CreateBranch"      => await github.CreateBranch(toolCall.Args),
            _ => throw new Exception($"Unknown tool: {toolCall.Name}")
        };
        messages.Add(new("tool", result, toolCall.Id));
    }
    // и снова идём в LLM — пока он не скажет stop
}

С SK:

kernel.Plugins.AddFromObject(new GitHubPlugin(token), "GitHub");
var settings = new OpenAIPromptExecutionSettings
{
    FunctionChoiceBehavior = FunctionChoiceBehavior.Auto()
};
await chat.GetChatMessageContentAsync(prompt, settings, kernel);

Весь этот while-loop, switch по именам тулов и склейка результатов обратно в messages — это и есть то что SK делает за тебя. И это просто капец как удобно!

В последние недели реально херачим с Женьком просто как кони! (не то что до этого мы проебывались. просто пахали как лошади, а тут прям разогнались так сказать)

Я когда про это рассказываю, то прилетает ОЧЕНЬ много вопросов о том, как мы с такми подходом не разносим прод.

Не очень понимаю, откуда может прийти пиздец, ну разве что мы агентов в прод базу не запустим)))) Но так мы делать не будем. НО НО!

Если чет разъебется так чтоб прям пиздец. Я обязательно расскажу тут)

В продолжение постов об исследованиях от METR

На скриншоте — количество задач, которые мы закрыли в последнем спринте командой из двух человек: 25 задач.

Для нашей команды это много. Очень много. Можете не считать стори-поинты, так как вряд ли эти оценки будут информативны, ибо они учитывают разработку с агентами, и 0.1 для агента спокойно может быть 0.5-1 для человека.

Причём у нас не было цели «закрыть как можно больше задач» или «поднажать в этом спринте» — это самый обычный спринт.

За исключением того, что наш бекендер, Дима, адаптировал под нас систему, придуманную другой командой из Додо, которая позволяет прожаривать карточки с помощью LLM.

Суть простая: мы берём юзер-стори → LLM исследует кодовую базу и все открытые/архивные карточки → на основе юзер-стори LLM пишет описание для карточки с техническими деталями и закидывает её к нам на доску → that's it.

Казалось бы, ничего революционного, но на деле — это офигенный способ использовать LLM в уже устоявшейся кодовой базе, так как она имеет нужный ей контекст и почти без ошибок угадывает, какие паттерны применить, куда положить файлы, как задизайнить API и так далее.

Ниже — то, как новый подход ускорил нас.

1. Даже в нашей небольшой команде прожарка задач была бутылочным горлышком.

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

2. Новый подход позволил нам распараллелить работу.

Так как все задачи прожарены наперёд, то я могу взять в работу задачу, для которой нужен бэк, понимая, что API не готово. И мне, в целом, без разницы, когда оно будет готово. Как будет готово — фича полностью заработает, а до этого момента просто будет скрыта от глаз пользователя.

Это особенно классно, учитывая то, что у нас есть много независимых задач, которые нужно делать только на фронте или только на бэке, из-за чего бывает очень сложно синхронизироваться, чтобы сделать/прожарить задачу, которая уже требует работы с обеих сторон. Сейчас эта проблема исчезла, ибо у нас просто отпала необходимость синхронизироваться друг с другом там, где это было необходимо раньше.

3. Мы можем брать задачи из другого домена.

Так на прошлой неделе наш менеджер, Оля, принесла юзер-стори, прожарила её через скилл в Claude Code, а затем на основе прожаренной карточки самостоятельно закрыла задачу.

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

Кстати, зацените распределение карточек по типам:
• 14 фичей
• 8 багов
• 2 технические задачи
• 1 исследование

То есть 32% закрытых карточек были багами. Думаю, что кому-то это число может показаться большим, поэтому давайте разберём, что там за баги:
• 4 бага связаны с огромной фичой на 70 тыс. строк (таблицы для Blok), которую я затащил за спринт до этого. Все баги — неучтённые edge-кейсы.
• 3 бага — те самые регрессии, которых все боятся при работе с агентами. Сценарии, в которых они возникали, уже покрыты тестами, так что снова не появятся:)
• 1 баг вообще находился не в нашем сервисе, но так как ребята из другого сервиса пока не могут пофиксить баг у себя, мы сделали изощрённую заплатку в нашем сервисе, до которой не додумались бы сами.

Так что, как видите, даже с учётом возросшей скорости и количества фичей, которые мы шипим, у нас произошло всего 12% регрессии за спринт. И это опять же очень классный результат!

P.S.
Уже в текущем спринте Оля закрыла ещё две задачи. Я их отревьюил и просто слил в мастер, так как доработки не требовались.

Да, пока Оля берёт в работу только небольшие задачи, но думаю, что со временем мы будем экспериментировать с карточками бо́льших размеров. Посмотрим, что из этого получится:)