Заметки об AI, системах и менеджменте

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

Проверяйте ноль, отрицательные значения и бессмысленный ввод до релиза, потому что первый реальный пользователь пришлёт то, что в спецификации не предусмотрели.

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

Считайте реальную стоимость токенов на один PR: на живых фичах она может в 10–100 раз превышать стоимость мелких тикетов.

Покадровая анимация на 120 Гц идёт вдвое быстрее; для easing нужно 1 − (1 − rate)^frames, а не rate × dt.

Локальная модель не восстановит информацию, которой нет: ей нужен глупый глобальный супервизор, который знает, когда перезапустить.

Защищайте регистрацию от массовой накрутки заранее, а не после письма с ультиматумом.

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

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

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

Задавайте поведение агента на уровне интерфейса: типизированные спеки тулов, изолированный контекст и структурированные ошибки вместо новых абзацев в промпте.

Для агентов оценивайте, доведена ли задача до конца за весь цикл, а не только по первому ответу.

Если оценку нужно снизить, режьте объём работ, а не торгуйтесь над цифрой.

Проверяйте AI-инструменты безопасности в условиях реального инцидента, а не только на демо.

После внедрения AI-инструментов для кода измеряйте cycle time и пропускную способность ревью, а не только объём кода.

Считайте тихое ревью сигналом риска и добивайтесь настоящего спора до начала разработки.

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

Прежде чем радоваться быстрой генерации кода, посмотрите на очередь ревью и закрывайте любой PR, который автор не может объяснить в двух предложениях без открытия диффа.

Спрашивайте про одну неизвестную, которая может сорвать оценку, и проверяйте её сразу, а не спорите о одной дате.

Оценивайте сеньоров по тому, понимают ли они, что не нужно строить, а не по знанию мелочей фреймворка.

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

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

Проектируйте систему, в которой люди принимают верные решения без вас, а не переназначайте их задачи каждые 30 секунд.

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

Называйте конкретный ценный результат вместо общих принципов, чтобы человек понял планку и смог повторить её эффективно.

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

Считайте внедрение главной инженерной задачей: сначала заслужите доверие и впишитесь в привычные процессы, а уже потом улучшайте модель.

Когда план рушится, выбирайте следующий хороший вариант вместо того, чтобы идти домой, и можете получить больше, чем потеряли.

Когда AI берёт на себя рутинные технические решения, тратьте силы на пользователей, эвалы и на то, решаете ли вы правильную задачу.

Считайте мелкие детали, которые видит пользователь, настоящими дефектами качества: доверие строится на том, что замечают люди, а не на внутренних метриках.

Превращайте каждую проблему, которую поднимаете, в конкретное решение с вариантами, чтобы команда понимала, что делать дальше.

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

Называйте ограничения (время, приоритеты, нехватку информации), как только их увидите, потому что молчание воспримут как согласие.

После провала к каждому объяснению добавляйте конкретное решение или новый план.

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

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

Называйте конкретные паттерны (SOLID, DDD) вместо расплывчатых целей, и тогда вы с AI будете говорить о понятных вещах.

Отдавайте ИИ рутину вроде CRUD и трансформаций JSON, а ответственность за результат оставляйте за собой.

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

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

Используйте AI-ассистента, чтобы превратить разрозненные заметки бизнеса в структурированный эпик и файлы задач до переноса в трекер.

Стройте повторяемые процессы через документацию, чтобы ИИ делал рутину, а люди принимали решения.

Как руководитель, ведите ключевые этапы найма сами, а не передавайте их другим.

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

Разбивайте сложную генерацию на специализированных агентов с понятными ролями, а не пихайте всё в один промпт.

Строите AI-процессы с фиксированным источником, понятными требованиями и человеком-валидатором до публикации.

Используйте AI для мелких задач, но картину системы держите в голове сами, особенно во фронтенде, где оценку UX делает человек.