Fedkin is thinking

Как чуть меньше страдать от нейрослопа Или небольшой полезный тех, который ты можешь сделать за пару дней Давеча я писал, что агенты без должного контекста о системе склонны к локально оптимальным решениям. Это часто приводят к: • нарушению направления зависимостей в коде • смешиванию доменной логики и инфраструктурной • странному неймингу и расположению классов Хорошая новость — многое из этого можно ловить детерминированными тестами Есть прекрасные инструменты, как например ArchUnit для Java (если знаете похожие инструменты для других языков, пишите в комменты), которые позволяют писать декларативные тесты на архитектуру приложения: Домен не должен зависеть от инфры: noClasses() .that().resideInAPackage("..domain..") .should().dependOnClassesThat() .resideInAPackage("..infrastructure.."); In-порты называются ...UseCase classes() .that().resideInAPackage("..port.in..") .should().haveSimpleNameEndingWith("UseCase"); Все порты должны быть интерфейсами: classes() .that().resideInAnyPackage("..port.in..", "..port.out..") .should().beInterfaces(); Потратив пару дней на обдумывание и написание таких правил в паре с агентом, можно заметно увеличить качество летящих в тебя пулреквестов, потому что они будут корректны как минимум по структуре. По ходу движения список правил может дополняться Как уже многие писали, разработка с агентами не привносит каких-то кардинально новых принципов, а только усиливает значимость старых добрых бест-практисов p.s.: зачем эти детерминированные проверки, если я могу дать агенту правила в виде текста: • промпты не дают гарантий • не проверяют уже написанный код

Несколько избитая тема, но мне кажется очень красивой идея, которая стоит за structured output в современных ллмках Задача — пользователь передает json-схему, нужно сгенерировать ответ строго по переданной схеме 1. Наивный вариант Подложить схему в контекст: ... Return a JSON object that strictly matches the following schema: { "type": "object", "properties": { "status": { "enum": ["SUCCESS", "FAILED"] } }, "required": ["status"], "additionalProperties": false } Будет ли работать? Да, в большинстве случаев. Но без каких либо гарантий, что схема в итоге будет корректная 2. Добавляется constrained decoding LLM генерирует ответ токен за токеном, на каждом шаге строя распределение вероятностей: "{" = 0.75 "status" = 0.20 ":" = 0.04 "answer" = 0.01 А дальше в процесс вмешивается constrained decoding Из json-схемы строится контекстно-свободная грамматика (CFG), которая позволяет понять, какие продолжения ответа в текущий момент всё еще могут привести к валидному результату Например, для схемы выше грамматика могла бы выглядеть как-то так: root ::= "{" ws "\"status\"" ws ":" ws status ws "}" status ::= "\"SUCCESS\"" | "\"FAILED\"" И, согласно грамматике, инференс-движок накладывает маску на распределение вероятностей следующего токена "{" = 0.75 "status" = 0.20 ":" = 0.04 "answer" = 0.01 Превращается в "{" = 0.75 "status" = 0 ":" = 0 "answer" = 0 Сгенерили { — "status" = 0.6 ":" = 0.3 "answer" = 0.1 Превращается в "status" = 0.6 ":" = 0 "answer" = 0 Сгенерили {"status" ... и так далее — С относительно небольшим оверхедом это позволяет генерить ответ, строго соответствующий схеме

Если ты слишком хорошо решаешь проблемы — возможно, ты решаешь не те Пост по мотивам одного из худших полугодий на работе:) Когда всё вокруг горит, мы начинаем преувеличивать значимость каждой конкретной проблемы. Каждая проблема кажется той самой, что нужно решить прямо сейчас. Естественная реакция на такое — сделать хоть что-то, что продвинет ситуацию вперед • Команды не договорились — синхронизировать • Сроки едут — заовертаймить • Где-то возник затык — лично прийти разблокировать ... Это дает ощущение движения и контроля — ты же что-то делаешь, постоянно кому-то помогаешь, с каждым разом все лучше и быстрее решаешь проблемы. Становишься эдаким эффективным пожарным. Результат у этого всегда один — выгорание и демотивация Что делать — вы и без меня знаете: остановиться и позадавать себе вопросов • А почему проблема дошла до меня? • Почему глобально система допускает возникновение таких проблем? • Что сделать, чтобы починить корневую причину таких проблем? В условиях горящих сроков и давления такое бывает сделать правда сложно, но нужно сделать волевое усилие и "zoom-out"-нуться Поэтому если ты N-ый раз решаешь одну и ту же проблему, подумай, ту ли проблему ты решаешь