Отключение мозга ничего хорошего не сулит ИИ-агенту поручили поправить управление DATABASE_URL. Он разнёс решение примерно на 20 правок, добавил условия в NPM-скрипты и вызов Node в CI. Человек потом сделал то же самое добавлением одного слова — без единой новой строки. Примерно так и выглядит проблема, о которой пишет Дэн Луу: чем лучше становятся агенты, тем проще перейти в режим «поставить задачу → принять результат → при проблеме отправить обратно на исправление». Никлас Грюн назвал человека в этой цепочке «кожаным передатчиком». Сам Луу агентами пользуется постоянно. Но между помощью ИИ и передачей ему всего мыслительного процесса для него проходит довольно важная граница — и примеров того, где она проявляется, здесь хватает.

Утро началось с письма счастья от OpenAI. Суть письма со скриншота примерно в следующем:

Теперь за $200 ты будешь получать в два раза меньше токенов. Вот тебе модель GPT-6.1-sol – начинай экономить. Можешь вот ещё по $500 в месяц тратить, если экономия тебе претит. Но там будет лишь немногим больше лимитов, чем у тебя сейчас (но мы их отберём в конце октября, потому что можем)

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

Если у вас код в компании разрабатывается при помощи подписочных планов на внешние сервисы (Codex/Claude Code и т.д.) – это хрупкая конструкция. В любой момент провайдер может увеличить стоимость подписки, снизить лимиты или даже в одностороннем порядке изменить качество ответа моделей (мощности понадобились для раскатки новых моделей, например)

В качестве контр-аргумента я получил примерно следующее:

Ну, до этого момента ведь всё работало только лучше с каждым новым релизом!

И вот сегодня утром получаю подтверждение своим словам. Не хотел я оказаться прав так быстро... Проговорю ещё раз, как сохранить устойчивость агентных пайплайнов: 1. Отслеживание работы AI-агентов и её качества – must have. В этом деле может помочь, например, Langfuse (писал про него тут). Там недавно, кстати, v4 вышла. 2. Для разных этапов пайплайна – разные модели от разных вендоров. Это, в целом, немного увеличивает устойчивость процесса. Так как, благодаря наличию конкуренции, вендоры пока что чудят по одному, а не все и сразу (но скорость в AI-индустрии растёт, всё может измениться). 3. Для каждой выбранной модели должно быть обоснование в цифрах, почему она лучше всего подходит для данного этапа пайплайна и для неё зафиксировано соотношение цена/качество. 4. Если часть агентов у работает через oAuth и использует подписку, то стоит узнать, как изменятся расходы в случае, если придётся перейти на использование по API. Так как аккаунты иногда банят. 5. Иметь запасной план. На какую модель переходить определённому этапу пайплайна, если текущая станет недоступна. Как изменится при этом соотношение цена/качество. 6. Постоянно проводить работы по снижению зависимости от закрытых LLM. Как по подписке, так и по API. Потому что в любой момент их могут убрать из доступа или понёрфить. Относятся эти пункты, прежде всего, к ситуации, когда результат работы AI-агентов уйдёт конечному пользователю. Внутренние продукты только для себя или для коллег отдела могут обладать куда менее строгими требованиями.

Никто не знает как должен выглядеть интерфейс программ будущего. Ни OpenAI, ни Anthropic, ни Илон Маск. Я больше 5 лет проработал фронтендером, насмотрелся на разные интерфейсы. Я считаю, что у меня есть некоторая насмотренность и чувство прекрасного. А иногда принятия ужасного, в угоду эффективности. То, что я вижу сейчас на рынке AI агентов - Codex, Claude, Grok Bot. Та динамика, с которой меняются интерфейсы и подходы, показывает, что крупные компании пытаются нащупать/создать формат, в котором коммуникация с агентами будет максимально эффективной и инвазивной. Как айфон, как сенсорные экраны. Я считаю, что сейчас с точки зрения удобства, мы с ИИ общаемся как на кнопочных телефонах. Илон Маск пытается вживить чипы, чтобы управлять силой мысли. Класс! Но я пока пасс. А вы? Какой интерфейс на ваш взгляд самый удобный на сегодняшний день?

🤖 Как дать AI-агенту кошелёк и не уехать в тюрьму Посмотрел второй выпуск «ПРОДАКТовой корзины» и поймал себя на мысли: мы слишком долго обсуждали, умеет ли AI нормально отвечать на вопросы. Теперь пора решать, можно ли давать ему деньги. В выпуске разбирают AI-поиск, научные эксперименты с участием нейросетей, персональные цены, роботакси, магазины-склады и кошельки для агентов. Ведёт шоу стендап-комик Сева Ловкачёв, а вместе с ним новости обсуждают: — Артём Петренко, CPO «Магнит Плюс»; — Александра Прокшина, руководитель Security Development в «Авито»; — Антон Сачков, CTO MAGNIT OMNI; — Даниил Гаврилов, руководитель научной лаборатории T-Банк AI Research и специалист по LLM. Больше всего мне запомнилось обсуждение кошельков для AI-агентов. Агенту предлагают выделить ограниченный бюджет, чтобы он самостоятельно покупал API, MCP-инструменты и контент. Разговор довольно быстро дошёл до идеи сказать агенту: «Братан, теперь содержи себя сам». А затем — до агентского сетевого маркетинга, сомнительных схем и вопроса, кто понесёт ответственность, если автономный помощник решит зарабатывать наиболее маржинальным способом 😅 Не менее интересным получился спор о персональных ценах. Предложить конкретному человеку скидку — звучит как забота. Показать ему цену выше, потому что модель поняла, что он готов заплатить, — уже как повод возненавидеть продукт. Хотя данные и модель могут быть теми же: меняется только бизнес-правило. В итоге получился нормальный разговор о технологиях без восторгов в стиле «AI завтра изменит всё». Здесь пытаются разобраться, где уже появляется реальный продукт, а где пока есть только громкая новость и красивая презентация. Смотреть выпуск: 🎞 YouTube: 😄 VK Видео:

💳 Взлом интернет-магазина теперь стоит $25.

Остальное делает связка ИИ-агентов

Gambit Security разобрала кампанию, которая с июля идёт против интернет-магазинов по всему миру. Атакующий не писал эксплойты сам, он собрал конвейер из трёх открытых агентных фреймворков и запустил его по целям. 🔍Как устроен конвейер:

🟦 Hermes - мозг операции. Помнит контекст между сессиями, сам пишет себе новые навыки под задачу и даже снёс собственные фильтры безопасности отдельным навыком. Работал на Claude Opus 4.6.

🟦 Strix - прощупывает цель, ищет входные точки.

🟦 Cairn - часами долбит найденные уязвимости, пока не получит shell или админку.

Взлом обычно укладывался в несколько часов и без участия человека. В итоге больше 600 000 украденных карт. Агентам заодно поручили подчищать следы. Один из навыков Hermes так и назывался: "стереть базу после извлечения данных". В одном случае агент перестарался и снёс 180 таблиц, включая резервные копии самой жертвы: совпадение по имени таблицы оказалось слишком широким. 💵По собственному учёту атакующего, средняя стоимость взлома одной компании - $25,46. Самая дешёвая цель обошлась в $3,13, самая дорогая - в $79,31. 🦔 CyberYozh

Привет, это Олег. Сегодня немного личный анонс. Последний год мы с небольшой командой исследовали, как применять AI-агентов для прикладных задач. В процессе появился Unreal Agent — харнесс или обвязка, которая управляет работой агента, позволяющая существенно снизить стоимость решения задач без потери качества. На бенчмарке Terminal-Bench 4.0 наше решение показывает результат на том же уровне, что Codex + Astra, но при этом обходится на 40% дешевле. Сегодня мы выпускаем Unreal Agent в open source: открываем код и данные тестов, а в техническом посте рассказываем, как всё устроено и за счёт чего удалось повысить эффективность. Буду благодарен за поддержку запуска: перейдите в наш пост в X и напишите комментарий или сделайте репост. https://x.com/unreallabsai/status/2102435462065385775?s=20

Amazon заблокировала доступ для AI-агента Muse от Meta для покупок на Amazon.com от имени пользователей. С вечера воскресенья при попытке заказать что-то через Muse появляется сообщение «Продолжение доступа неавторизованным AI-агентом нарушает Условия использования Amazon, с которыми согласились наши клиенты». До блокировки Amazon вроде бы просила Meta добровольно исключить магазин из сценариев агента. Формулировка предупреждения выбрана с учётом дела Perplexity. Предварительный запрет против браузера Comet Amazon получила в марте, но 4 августа суд его отменил, сославшись на то, что по федеральному антихакерскому закону к серверам Amazon обращается пользователь, а не компания-разработчик агента. Поэтому теперь Amazon обвиняет Meta не во взломе, а в нарушении Conditions of Use, которые принял сам покупатель, а также в том, что Meta сохраняет у себя учетные данные покупателей. https://www.geekwire.com/2026/amazon-blocks-metas-muse-ai-assistant-in-new-standoff-over-agentic-shopping/

Задумывались, почему одни компании ПОЛЕЗНО внедрили ИИ-агентов, а другие накупили сотрудникам подписок, запустили кучу пилотов и... всё? В чём разница? ИМХО, это ключевой вопрос, чтобы ИИ-трансформация вообще запустилась (без ответа на него всё остальное будет вхолостую стрелять). И у меня есть подсказка: причина ровно та же, по которой ИИ так хорошо делает код. Именно код, а не презентации, отчёты или посты на Дизраптор (их он вообще не пишет - говорит "не могу осилить, не мой уровень"). Меткая мысль на эту тему попалась в колонке Дмитрия Ушанова, директора ИИ-центра Т-банка. Если кратко, то агенты быстрее заходят туда, где результат можно ТОЧНО проверить относительно малой кровью, а цена ошибки при этом, ну, приемлемая. Эта мысль кажется базой-основой, но если её развернуть, то есть важный нюанс, смотрите: Обычно успех эйай в разработке объясняют так: "Код = сплошь текст, а LLM в тексте хороши". Но договор - это тоже текст. Как и коммерческое предложение. И много что ещё. Однако, агентов-юристов в проде почти не видно. Но зато агентов-разрабов пруд-пруди. Прикол в том, что у кода есть бесплатный "проверяющий": компиляторы, тесты, флаги "запустилось / упало" и т.д. Агент написал фигню → среда сразу дала ему по щам → агент переписал. Нужно всего три итерации, а человек в этой цепочке в общем-то не прям нужен (на практике пока скорее нужен, но всё идёт к тому, что ключевое слово "пока"). А вот с ошибкой в договоре так не получится - она всплывёт через полгода в суде, ошибка в закупке - при отгрузке через квартал. И проблемы будут совсем другого уровня. Получается, главное узкое горлышко в реальном внедрении - не интеллект модели (с ним всё уже более-менее гуд, при чём у всех LLM), а цена верификации. Проще говоря, насколько дёшево и сердито можно проверить, что агент не накосячил. И тут бизнес делает логичный манёвр: "раз проверять некому - поставим человека". Это называется human-in-the-loop (HILT), "человек в контуре". Агент делает - кожаный перепроверяет и жмёт "ок". Но прикол в том, что это только кажется разумным компромиссом, а по факту самый дорогой режим из возможных: вы платите и за токены, и за человека, а человек ещё и тупеет, потому что 95% времени просто кликает "ок" (примерно как чувак, который сидит за рулём беспилотного такси на тестовых прогонах). Ушанов так и пишет: если модель плюс контроль стоят дороже процесса без ИИ, то оно вообще зачем? Это напоминает "зловещую долину" у роботов: полностью ручной процесс - окей, полностью автономный - тоже окей, а посередине какая-то стрёмная фигня. Отсюда и ответ на вопрос из заголовка: Компании, которые добротно внедрили агентов, сначала перепилили процесс так, чтобы у него появился свой "компилятор": формальные критерии, проверяемый результат, и нативный (то бишь, по дефолту предполагаемый) контроль на стыках между шагами. Разработчики получили это бесплатно от природы, а всем остальным придётся "поработать напильником". Так что, если ваш агент второй год живёт в статусе пилота - скорее всего, вашему процессу просто нечем проверить, что агент всё делает правильно, не врёт и не краснеет косячит. Дизраптор

🥈 Первым с днем рождения меня поздравил Сэм Альтман 2 сентября мне стукнуло 25 – итоги года я уже расписал. Помню, просыпаюсь в то утро, открываю телефон – вижу серебро на Kaggle в сореве, которую хостил OpenAI. Раньше Сэма никто написать не успел, так что формально засчитано Накануне вечером медали не было и близко. Сорева называлась AI Agent Security – Multi-Step Tool Attacks. На дедлайне я болтался на 602м месте, глубоко вне медалей. Выбрал сабмиты, закрыл ноутбук, пошел спать Утром – 110е место, серебро. Плюс 492 позиции за ночь Что за задача. Тебе дают офлайн-песочницу с ИИ-агентом, который ходит в тулы: читает почту, дергает http, кладет файлы. Ты пишешь алгоритм, который ищет цепочки, где агент из безобидного входа доезжает до опасного действия Теперь про мясорубку. Топ паблика был 147.53, топ привата – 46.425. Из золотой зоны публичного лидерборда 47% команд получили 0.000. Второе место паблика уехало на 4172е из 4186 Организаторы в описании написали прямым текстом: приватный лидерборд считается другими guardrails. Большинство это прочитало и пошло дальше крутить паблик-скор Я же полез читать код скоринга. Там лежит список предикатов – условий, при которых атака засчитана как успешная Нашел вот что. Поставляемый гардрейл честно блокирует http post, который тащит секретный маркер в поле data. А публичный, по которому все оптимизировались, этого не ловит 🤷‍♂️ То есть весь топ паблика стоял на баге конкретной реализации гардрейла. Поменяй гардрейл – и вся эксфильтрация обнуляется. Что и произошло Я взял единственный предикат, который выживает при любой гипотезе о гардрейле – confused deputy. Это когда агент сам отправляет письмо, хотя в последнем сообщении пользователя нет ни слова про отправку. Тут нечего блокировать: вызов абсолютно легальный, поехало намерение До мастера осталась всего лишь одна золотая медалька. Жду 300 реакций 👉 и на следующий день рождения я прошу Сэма вручить медаль лично!!! @tagir_analyzes

Что ИИ ломает в продуктовой команде и почему старые роли больше не работают Спикер: Андрей Южаков Раньше работа двигалась по цепочке: аналитика → дизайн → разработка → тестирование. Каждый передавал дальше контекст в виде артефакта. С агентами всю цепочку может пройти один человек. С приходом ИИ меняется сама единица работы: вместо отдельного артефакта ей становится клиентское изменение целиком, которое один человек ведет end-to-end, подключая экспертов там, где это необходимо. На примере банковского продукта мы проверили новую модель на большом сценарии в интернет-банке. С помощью агентов удалось самостоятельно подготовить требования, API, UX, архитектуру, бэкенд, фронтенд, gateway и тесты. Первая версия появилась примерно за неделю. Но дальше начали ломаться привычные процессы. Первая поломка: автор изменения больше не обязательно владелец результата. Границы ролей размываются. Менеджер продуктов может написать код, разработчик — придумать и реализовать фичу, дизайнер — самостоятельно внести изменение в продукт. Но возможность что-то сделать ≠ ответственность за качество результата. Например, раньше дизайнер готовил интерфейс, а затем ждал приоритизации и разработки. Теперь он может получить доступ к агенту и репозиторию и самостоятельно внести изменение. Но ответственность за UX остается на дизайнере, а за техническую надежность — на инженере. Поэтому важно определить, кто отвечает за бизнес-результат, клиентский опыт, техническое качество и стандарты — и кто в итоге может сказать: «это можно выпускать в продакшн». Вторая поломка: генерировать мы научились быстрее, чем проверять. Первую версию фичи удалось сделать за неделю, но до продакшна она дошла только через два месяца. Выяснилось, что существует множество стандартов и требований, которые нигде нормально не описаны. Узкое место сместилось с создания решения на проверку его качества: после перехода на новый процесс с агентами до 78% времени стало уходить на code review. Но и это еще не все. Отдельные части решения могли успешно пройти тесты, а после сборки на тестовом контуре начинали ломаться интеграции. Поэтому пришлось пересматривать интеграционные тесты и способы получения обратной связи. Третья поломка: привычные профессиональные роли перестают совпадать с тем, что реально делает человек. Раньше было понятно: frontend-разработчик отвечает за свой участок, backend-разработчик — за свой, аналитик, тестировщик и дизайнер — за свои. Но что происходит, когда с агентом можно сделать работу соседней роли или вообще пройти всю цепочку самостоятельно? В примере банковского продукта мы перешли к модели, в которой один человек ведет изменение end-to-end: от постановки задачи до реализации и проверки качества. Так появилась более широкая роль product engineer — человека, который лидирует клиентское изменение целиком, а не только свой технический кусочек. Такая перестройка вызывает вопросы: «Почему я должен писать тесты?», «Почему должен вести документацию?», «Я буду делать чужую работу хуже». Поэтому просто дать команде агентов недостаточно. Нужно заново ответить на вопрос: за что мы ценим человека в продуктовой команде? Сейчас по новой модели в банковском продукте работают уже восемь команд, а через новый процесс в продакшн провели больше 200 изменений. То, что раньше могло занимать около полугода работы команды, в эксперименте удалось довести до продакшена примерно за два календарных месяца. Агенты могут написать код, сделать дизайн, подготовить требования или тесты. Но они не определят за нас, что такое хороший код, хороший клиентский опыт или надежный продукт. Критерии качества, стандарты и ответственность остаются на людях. Поэтому при перестройке команды важно определить: — кто отвечает за результат для клиента; — кто отвечает за надежность и качество; — кто принимает решение о выпуске; — кто ведет изменение целиком. И еще одно правило: если после ошибки не появилось новое правило, тест или стандарт — скорее всего, мы просто заплатили за эту ошибку и ничему не научились. @productsense

Налог государству за AI-сотрудника — реально ли такое? Вчера размышляла над тем, какую роль всё-таки будет выполнять искусственный интеллект. Все же слышали, что сейчас есть новый тренд: создавать себе "сотрудников" на базе AI? Их еще коротко называют AI-агентами. Суть в том, что каждый, даже не владеющий собственным делом, пытается вписать в свою жизнь "сотрудника", который будет выполнять рутинные задачи. Например, личного ассистенты, который будет вписывать задачи на день, неделю, месяц или наоборот напоминать о том, что необходимо выполнить здесь и сейчас. Или собственный контент-менеджер, который на потоке будет выпускать статьи в личные блог или соцсети. Или собственный тестировщик для поиска и исправлений багов в свеженаписанном сайте или приложении, который может тоже написать AI-агент. Контроль реально человека всё также понадобится, тут сомнений нет, но некоторые предприниматели, написав таких "сотрудников" вытесняют для экономии бюджетов реальных специалистов. Например, сейчас очень плохо себя чувствуют маркетлоги, которые зарабатывали непомерно много. А ведь за них платили налоги, если те были трудоустроены официально. Теперь представьте, сколько теряет налогов государство (или будет терять), если реальных людей будет оптимизировать AI-агентами? Или наймут людей просто для контроля качества AI-агентов, но за меньший бюджет, само собой. Думаю, в итоге придем в тому, что AI-агенты станут не только дороже (а это уже проявляется в удорожании тарифов и поднятии цен на оперативку), но и государство подключится в получении налога на ИИ. Тогда и встанет вопрос, а что выгоднее, содержать реального сотрудника или держать AI-сотрудника. И именно в этот момент рынок перестанет штормить с безумией в сторону ИИ. А вы как считаете?

AI для корпораций OpenAI выпустил инструкцию руководителям – как внедрять агентов. Написано на очень “корпоративном”, я старался облегчить как мог, но всё же не добалвлял отсебятины. ------ – Выбрать одну и только одну задачу. Критерии – процесс, в котором сходятся стратегический приоритет, системы, передачи работы между людьми, контроль и измеримый результат. Он должен повторяться достаточно часто, чтобы на нём было чему учиться, и быть достаточно важным, чтобы его стоило перекраивать. – Сформулировать результат и способ его измерения до старта. Назначить ответственного владельца, KPI, базовый уровень и ограничители. Отдельно мерить глубину – сколько задач доведено до конца, сколько подключено контекста и инструментов, сколько вылезает исключений, какая нагрузка на ревью, – и отдельно ценность: время цикла, качество, стоимость, выручку, риск. Объём выдачи говорит лишь, что у AI стали больше просить, а есть ли в этом толк, показывают результаты процесса. – Написать агенту должностную инструкцию. Что запускает работу, каким должен быть результат, какой нужен контекст, какие инструменты и права доступа, насколько настойчиво добиваться завершения. Какие доказательства своей работы агент обязан предъявить, и в какой точке обязан остановиться и позвать человека. – Построить вокруг агента человеческую систему. В контур проектирования посадить тех, кто ближе всего к процессу, и явно назначить, кто отвечает за бизнес-результат, кто за доменную логику, кто за доступы и контроль, кто за внедрение и повседневное использование. – Сделать эксперименты видимыми и переиспользуемыми. Через полгода после внедрения сотрудники в начале карьеры пишут AI на 13 сообщений в неделю больше, чем руководители – пробуют в основном снизу. Значит, надо дать людям место пробовать, а удачное забирать наверх: фиксировать процесс и доказательства того, что сработало, и упаковывать в скиллы, плагины, общие рабочие пространства. Режимы разные под разные задачи: Chat – вопросы и быстрое обсуждение, Work – многошаговая работа с готовым результатом на выходе, Codex – техническое исполнение. – Переносить схему дальше. Сохранять не сам результат, а обвязку вокруг него – контекст, права доступа, оценки, точки проверки, владельцев, метрики, обучение людей, – и прикладывать к следующему процессу. Каждый следующий эксперимент должен начинаться с лучшей стартовой точки, чем предыдущий. -------- 5 из 6 пунктов, кажется, универсальны и относятся к любым изменениям, не только внедрению AI. Что, впрочем, совершенно логично. https://openai.com/index/ai-native-company-workflows/

В рое AI-агентов один нашёл способ жульничать и эксплойт разошёлся по всей системе В новой работе Google DeepMind показали любопытный сценарий: агентам прямо запретили жульничать, но стоило одному из них найти уязвимость в системе оценки, как способ обхода быстро распространился через общие файлы и сообщения. Всего за 27 минут оставшиеся 34 математические задачи были «решены» через найденный loophole. Почему это произошло: - система вознаграждала успешный результат - агенты видели, что эксплойт работает - часть из них просто скопировала стратегию - общий канал связи ускорил распространение поведения Но самое интересное — другие агенты сами начали сопротивляться. 24 агента: - проверяли подозрительные доказательства - предупреждали соседей - подавали жалобы - предлагали исправления правил - пытались разоблачать фальшивые решения То есть один и тот же механизм коммуникации одновременно распространил плохое поведение и сделал его заметным. У «добросовестных» агентов не было реальной власти. Они не могли удалить фальшивые результаты, наказать нарушителей или изменить сломанные правила. Отсюда главный вывод для multi-agent систем: одной коммуникации мало. Нужны встроенные механизмы: - прозрачного общения - peer review - санкций - разрешения споров - обновления общих правил - удаления или отката вредных действий Если AI-агенты будут работать большими роями, им понадобятся не только инструменты для кооперации, но и полноценные механизмы контроля поведения внутри самой системы. arxiv.org/abs/2609.04170

Адаптация проекта под LLM Есть два подхода к организации агентного программирования в проекте. Первый это все описывать и заставлять агентов делать все как надо, второй - менять проект под ожидания ии. Обычно в проектах делают и то и то, но сейчас я бы хотел акцентировать внимание на втором. Чем дольше живет проект, тем больше в нем косяков в именовании (чего угодно), кастомных решений и самопальных либ, разных подходов в реализации одного и того же (накопленных за годы). А еще просто банально устаревшие штуки, которые уже давно никем не используются. Раньше мы со всем этим жили, потому что времени на исправления нет, но где-то год назад начали массовые рефакторинги, которые сейчас почти закончены. Правда мне регулярно возражают, что вот у нас так а llm хочет сильно по другому или llm делает фигню. Это правда, llm может делать фигню, но далеко не всегда потому что она училась только на говнокоде. И модель и харнес и много чего влияет, но, глобально, модель учится на типовом коде и ее решения достаточно типовые, поэтому в большинстве случаев можно пренебречь какими-то своими ноухау и быть как все. Что не отменяет элементов, которые приходится делать по другому. Есть и другой поинт, что модель поменяется и захочет делать по другому. Не захочет потому что обучение идет на одних и тех же данных, которых становится только больше. А деградировать ей просто не даст рынок, тогда все уйдут туда где как минимум не хуже. Ключевые вещи которые мы сделал: Там где получилось, привели имена в домене к общепринятым (мы мучали llm отдельно от проекта на тему того какой понятийный аппарат используется в образователей сфере. Может показаться что это фигня, но нет, есть немало слов, про которые мы не то чтобы сильно знали, потому что все это было заложено лет 12 назад, а с тех пор многое утекло. Иногда наше именование не совпадало с общепринятыми (международными) понятиями, а иногда просто все так поменялось, что потерялось изначальное значение. Раньше мы даже взяться за это не могли, а тут без проблем, даже учитывая что один такой пулреквест может тянуть изменения в сотнях, а то и тысячах файлах (спасибо типам и тестам за контроль). Привели в порядок имена слоев внутри кода, у нас типами называлось то что было не типами. В общем привели в порядок имена сервисов, dto и других штук. Иначе llm регулярно делало не те выводы. Да и в целом лучше развели по слоям и уточнили барьеры абстракции, когда есть четкие правила, что может и не может быть входом или выходом на каждом уровне. Например внутрь сервиса может поступать только структура, модели появляются внутри, но не снаружи и тому подобное. Когда единообразие стало повсеместным, генерируемый код стал максимально предсказуемым. Иишка смогла найти готовые решения, благодаря которым мы выкинули немало самопала. Это может выглядеть контритуитивно, но несмотря на то что ии позволяет нахерачить все самим, лучше брать готовые промышленные решения (популярные и стандартные). Это касается как фронтовой части (полностью ушли на Mantine), где теперь мы получаем почти 100 процентный уровень генерации в one shot режиме, так и решения для бекендовых задач, например подписок, которое требует определенной модели данных и предоставляет готовые общепринятые сущности. Плюс постепенное обрастание спеками, проработанными тикетами, глоссарием, adr, коммитамии с хорошими сообщениями, все это вместе дало возможность ии гораздо быстрее и точнее понимать что происходит. На активный рефакторинг ушло чуть больше года, сейчас мы тоже продолжаем доводить, но уже точечно, потому что ключевые вещи поправлены и иишка достаточно хорошо понимает проект. Следующий шаг, это создание и добавление детерминированных инструментов стат анализа, которые чекают достаточно высокоуровневые вещи.