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

Генерация кода: сокращаем рутину в разработке Задача простая: во всей кодовой базе поменять print на logger.info. Поиском и заменой не выйдет, заденешь комментарии, где print просто упомянут словом. Синтаксическое дерево умнее — проходит по узлам, находит именно вызовы print, меняет только их. Но у абстрактного дерева (AST) своя цена. Код после трансформации становится чище и теряет всю документацию, потому что комментарии и форматирование оно не хранит в принципе. То есть безопасно рефакторить внутри репозитория им нельзя. Автоматизация давно не роскошь, а базовый минимум, и жертвовать читаемостью ради неё смысла нет. Остаётся третий инструмент, который держит всю структуру от запятых до комментариев. Посмотрим, чем конкретное синтаксическое дерево закрывает то, на чём спотыкаются два предыдущих.

Лучший ход Кажется, я долго искал критерий хорошего архитектурного решения. Сейчас думаю про четыре штуки, которые одновременно делает "лучший ход":

1. Даёт локальную пользу уже сейчас. 2. Уменьшает глобальный разрыв в системе 3. Делает следующий хороший ход дешевле. 4. Увеличивает вероятность того, что этот путь повторят другие.

Последний пункт кажется самым важным. Если решение приходится каждый раз продавливать заново, ландшафт не изменился. Настоящий рефакторинг: изменение формы поверхности, по которой движется вся система, без переписывания кода.

После хорошего рефакторинга правильное решение начинает требовать меньше усилий, чем неправильное.

Возможно, именно это и является настоящей единицей эволюции сложных систем. Если так смотреть, эволюция сложных систем идёт не через новые объекты, функции или процессы. Она идёт через сдвиги в стоимости следующего перехода. Хороший пример из нашей работы — текстовый daily в Slack по шаблону «доставлено / планирую / блокеры». Проверяется по всем четырём пунктам: Локальная польза сейчас — утром за 2 минуты команда видит, кто чем занят, без созвона. Закрывает разрыв — не нужно дёргать людей в личку «ну что там у тебя», блокеры всплывают сами. Удешевляет следующий шаг — если у кого-то затык, помочь можно сразу, а не когда уже сгорело. Повторяют другие — новый человек в команде заходит в канал, смотрит вверх, копирует формат. Никто не объясняет заново. Форма поверхности изменена: написать по шаблону дешевле, чем не написать. Поэтому шаблон живёт сам, без напоминаний. А теперь посмотрите на свою команду. Поищите такие примеры — где хороший ход стал дешевле плохого сам собой, без напоминаний и продавливания. Делитесь в комментариях. Давайте обмениваться опытом 👇

Как экономить контекст в coding agent (claude, codex etc.) Задача переписать легаси на сотни тысяч строк кода, которая разрабатывалась (криво и косо) на протяжении 5 лет, за 3 месяца. Сюда входит погрузиться: в продукт, инфру, архитектуру, нагрузку, тестирование и проч. Чтобы успеть, нужно смерживать десятки PR/день. Когда нибудь напишу, как мы построили процесс, а пока простые мысли, как экономить контекст, ибо что в лимиты упираешься постоянно. 1) Субагенты строго через младшую модель. Пример: Opus 5 оркестратор, Sonnet 5 субагенты. Идеальный сценарий когда младшая никогда модель не принимает никаких решений. 2) `/compact` каждые ~150k токенов: сейчас, когда у моделей по 1м контекстного окна, мозгу кажется что 250k это всего лишь 1/4, то есть мало, а по факту 250k это 250k, и с каждым след.запросом стоимость возрастает. Какое бы не было контекстное окно, я держусь в минимальных пределах. 3) По одной задаче на чат: допускал ошибку, когда давайл скоуп задач в стиле "/goal работай пока не закроешь все". Работает херово. Не потому даже что модель путается, а просто потому что вам так сложнее понять статус и прогресс. Понимание происходящего ценно, держитесь за него. Еще помогают четко описанные задачи, но это уже не просто об оптимизации токенов, а в целом о качестве. Пример секций: что делаем, зачем, что входит в задачу а что нет, как проверить задача успешно выполнена.

Хорошие инструменты — невидимы Ты долго собираешь хитрый макрос под разовую задачу по рефакторингу, наконец он срабатывает, и накрывает приятное чувство собственной сообразительности. А рядом кто-то сделал бы то же самое за минуту мультикурсорами или коротким скриптом. Инструмент, который превращает банальную смекалку в героический поступок, кажется мощным, хотя на деле он просто медленный. Дальше срабатывает вторая ловушка. Ты уже вложил месяцы в освоение редактора, он стал частью того, как ты себя ощущаешь, и теперь признать его недостатки означает признать свои. Поэтому их перестают терпеть молча и начинают защищать, а в итоге чествуют как достоинства. Честная проверка при этом простая, и она не про то, насколько умным ты себя почувствовал. Попробуем понять, по чему на самом деле мерить, служит инструмент тебе или ты ему.

ПРОКЛЯТИЕ ПЕРЕИСПОЛЬЗУЕМОСТИ Делюсь болью. Я последние 5 лет на разных уровнях у разработчиков, лидов и техдиректоров, активно встречаю такой паттерн:

Ну давай просто выделим общее и переиспользуем это в другой системе/проекте.

Мы ведь уже написали систему перемещения для ботов, давайте для игрока её тоже переиспользуем. У нас ведь уже есть backend-сервис по обработке match-3 логики, давайте его же тупо используем в другой игре 😵 Может казаться, что нужно просто скопировать/вставить решения из одного места или создать общий класс. И черт, это не работает нормально в большинстве случаев. 🔸 Если вы делаете что-то общее, то сначала нужно понять, какие зависимости это общее в себя принимает и отдаёт Если вы сделаете прямой copy/paste, придётся писать кучу обёрток, чтобы подружить новую систему с текущей. Поэтому чтобы действительно такое было возможно, нужно заранее проектировать не только саму систему абстрактно, но и её зависимости 🤯 А это значит, что нужно изначально планировать проектирование ключевых абстракций проекта. Например: 🔹 Весь cross-cutting context. Логирование, конфиги, аналитика, обработка ошибок. Либо придётся кучу мест рефакторить, либо заранее согласовывать единое API для переиспользования между проектами. 🔹 Коммуникация с сервером — пример посложнее. Но суть простая: вы не хотите при переносе дублировать логику обработки ошибок, контрактов взаимодействия и тянуть лишние транзитивные зависимости (другой HTTP-плагин, например). И это важно тупо потому, что это заставляет поддерживать задублированные решения по проекту 🤢 🔹 Изменился формат логирования или когда логи пишутся, а когда нет 🔹 Добавился новый обработчик исключений, формат контракта или обработка краевого случая Вот иди свищи по проекту 10 копий и вкостыливай фикс и туда. При этом ладно этот фикс в коде, ха, это ещё изи, а если ты решил общий микросервис такой выделить… 🔻Чем больше расстояние между зависимостями — тем сложнее и дороже в них вносить изменения. 🔸 Не всё, что кажется общим, таковым является Избитый троп:

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

Ну нет, это не работает. Если заранее не понимать, как именно система будет переиспользоваться, и не переиспользовать сразу — оно не будет работать. Это происходит из одного простого факта: 🔹 Скорость изменения требований разная для каждой из систем. То, что вчера виделось как общее, сегодня жёстко заточено под что-то конкретное, т.к. переиспользуемость стоит времени, сил, денег и тщательного планирования. Или по другому: То что вчера казалось легко можно переиспользовать, сегодня требует узкого и конкретного решения. Так что всё, пожалуйста, я снимаю со всех, кто читает этот пост, «проклятие переиспользуемости» 😘 С этого момента вы можете не писать системы так, чтобы вдруг когда-то их кто-то использовал и сократил себе время. 🔻 Наконец-то можно писать системы, которые заточены на выполнение своей задачи и не раздувают сложность проекта на ровном месте. Но если переживаете, вот правило трёх:

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

А если есть требование — выровняйте уровень знаний, покажите цену такого решения, сделайте #проектирование@UniArchitect, внедрите и пользуйтесь на здоровье, все только спасибо скажут. Ставь 👍 если тебе заходит такого рода контент! Ты знаешь кому переслать эту статью 💪 #проект_в_разработке@UniArchitect