Как ИИ балансирует производительность, читаемость и простоту в коде

Что значит балансировать производительность, читаемость и простоту

Прежде чем судить, «сбалансировал» ли ИИ что-либо, полезно назвать, о каком именно коде идёт речь.

Логика приложения — это код, который выражает правила и рабочие процессы вашего продукта: проверки прав, решения по ценообразованию, переходы состояний заказа, права доступа и шаги «что будет дальше». Это часть, наиболее связанная с бизнес-поведением и чаще всего изменяющаяся.

Инфраструктурный код — это подпитка: подключения к БД, HTTP‑серверы, очереди сообщений, конфигурации деплоя, пайплайны логирования и интеграции. Это важно, но обычно здесь не кодируются основные правила приложения.

Три цели — и что они реально означают

Производительность — код выполняет задачу за разумное время и с разумным потреблением ресурсов (CPU, память, сетевые вызовы, запросы к БД). В логике приложения проблемы с производительностью чаще всего вызваны лишним I/O (слишком много запросов, повторяющиеся API‑вызовы), а не медленными циклами.

Читаемость — коллега может точно понять, что делает код, зачем он это делает и где его менять — без «отладки в голове» целый час.

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

Почему эти цели конфликтуют в реальных проектах

Улучшение одной цели часто напрягает другие.

Кэширование может ускорить, но добавляет правила инвалидации. Сильная абстракция убирает дублирование, но делает поток труднее проследить. Микрооптимизации уменьшают время выполнения, но размывают намерение.

ИИ тоже может «пересолить»: он может предложить обобщённые паттерны (фабрики, объекты-стратегии, сложные хелперы), тогда как простая функция была бы понятнее.

Что значит «достаточно хорошо»

Для большинства команд «достаточно хорошо» — это:

• Чёткий контроль потока и имена, с минимальной абстракцией
• Производительность, соответствующая текущим SLA, с очевидными узкими местами избегаемыми (особенно лишние обращения к БД/API)
• Простые швы для тестирования, чтобы изменения можно было вносить безопасно

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

Как ИИ обычно выбирает структуру кода

ИИ не «решает» структуру кода так, как это делает инженер. Он предсказывает следующие наиболее вероятные токены на основе вашего запроса и паттернов, которые видел. Это означает, что форма кода сильно зависит от того, что вы просите и что показываете.

Он оптимизирует под то, что вы запрашиваете (и под ваши примеры)

Если вы просите «самое быстрое решение», вы часто получите дополнительные кэширования, ранние выходы и структуры данных, нацеленные на скорость — даже когда выигрыш минимален. Если просите «чисто и читаемо», вы получите более описательные имена, меньшие функции и понятный контроль потока.

Предоставление примера или существующего стиля кода ещё сильнее направляет модель. Модель будет зеркалить:

• соглашения по неймингу и границы функций
• паттерны обработки ошибок (исключения против возвращаемых значений)
• предпочитаемые абстракции (хелперы, сервисы, репозитории)

Частые неудачные режимы, которые стоит отслеживать

Поскольку ИИ хорош в сборке паттернов, он может сместиться в «хитроумные» решения, которые выглядят впечатляюще, но сложны в поддержке:

• Переинжиниринг: лишние слои, фабрики, интерфейсы или универсальные хелперы для простой фичи
• Хитрый код: плотные однострочники, сложные генераторы или функциональные цепочки, скрывающие намерение
• Преждевременная оптимизация: микрооптимизации (ручное кэширование, кастомная сортировка) без замеров

Данные обучения формируют стиль и дефолты

ИИ учится на большом миксе реального кода: чистых библиотек, поспешного прикладного кода, решений для интервью и примеров из фреймворков. Эта вариативность объясняет, почему вы можете видеть непоследовательные решения — иногда идиоматичные, иногда чрезмерно абстрактные, иногда громоздкие.

Финальный выбор — всё ещё за людьми

Модель может предложить варианты, но она не знает всех ваших ограничений: уровень команды, договоры кодовой базы, бо́евая нагрузка, сроки и стоимость поддержки в долгой перспективе. Рассматривайте вывод ИИ как черновик. Ваша задача — выбрать, какой компромисс действительно нужен, и упростить код, пока намерение не станет очевидным.

Треугольник компромиссов в повседневной логике приложения

Повседневная логика приложения живёт в треугольнике: производительность, читаемость и простота. Сгенерированный ИИ код часто выглядит «разумно», потому что пытается удовлетворить все три цели — но в реальных проектах вам придётся выбирать, какой угол важнее для конкретной части системы.

Компромиссы, которые вы узнаете сразу

Классический пример — кэширование против ясности. Добавление кэша может сделать медленный запрос быстрым, но также порождает вопросы: когда истекает кэш? что происходит после обновления? Если правила кэша не очевидны, будущие читатели будут неправильно использовать его или «править» некорректно.

Ещё одно напряжение — абстракции против прямого кода. ИИ может вынести хелперы, ввести универсальные утилиты или добавить слои («service», «repository», «factory»), чтобы выглядеть аккуратно. Иногда это улучшает читаемость. Иногда это прячет бизнес‑правило за уровнем косвенности, и простые изменения становятся сложнее.

Когда микрооптимизации вредят пониманию

Малые трюки — предварительное выделение массивов, хитрые однострочники, отказ от временной переменной — могут сэкономить миллисекунды и стоить минут человеческого внимания. Если код находится вне критического пути, такие микрооптимизации чаще приносят вред. Понятные имена и прямой поток выигрывают.

Когда «просто» становится медленно при росте

С другой стороны, самый простой подход может развалиться под нагрузкой: запрос внутри цикла, повторное вычисление одного и того же значения или выборка лишних данных. То, что читается хорошо для 100 пользователей, может дорого стоить при 100000.

Практическое правило большого пальца

Начните с максимально читаемой версии, которая корректна. Затем оптимизируйте только там, где есть доказательства (логи, профилирование, реальные метрики задержки), что код — узкое место. Это сохраняет понятность вывода ИИ и при этом позволяет «заработать» производительность там, где это действительно важно.

Как запрашивать у ИИ правильную логику

ИИ обычно делает то, что вы просите — буквально. Если ваш запрос расплывчат («сделай быстро»), модель может придумать сложность, которая вам не нужна, или оптимизировать не ту часть. Лучший способ направить результат — описать, каким должно быть «хорошо», и что вы не пытаетесь делать.

Начните с критериев приёмки (и не‑целей)

Опишите 3–6 конкретных критериев приёмки, которые можно быстро проверить. Добавьте не‑цели, чтобы предотвратить «полезные» отклонения.

Пример:

• Критерии приёмки: «Должно возвращать результат за <200ms для 10k записей; ошибки — удобочитаемые; функции — не длиннее ~40 строк.»
• Не‑цели: «Без кэширования; без новых зависимостей; без изменений схемы БД.»

Укажите ограничения, которые модель не может угадать

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

• целевые латентности (p95, p99 если есть)
• размеры данных и ожидания роста
• конкуренция (один пользователь против множества параллельных запросов)
• лимиты памяти (серверлесы, мобильные устройства и т. п.)

Хотя бы примерные числа лучше, чем отсутствие данных.

Попросите «простую первую версию» и «оптимизированную версию»

Запросите две версии явно. Первая должна отдавать приоритет читаемости и простому контролю потока. Вторая может добавить аккуратные оптимизации — но только если они остаются объяснимыми.

Write application logic for X.
Acceptance criteria: ...
Non-goals: ...
Constraints: latency ..., data size ..., concurrency ..., memory ...
Deliver:
1) Simple version (most readable)
2) Optimized version (explain the trade-offs)
Also: explain time/space complexity in plain English and note any edge cases.

(Этот блок кода оставлен без перевода намеренно — он должен остаться как пример запроса.)

Требуйте объяснений и оценки сложности простыми словами

Попросите модель обосновать ключевые проектные решения («почему эта структура данных», «почему такой порядок ветвлений») и оценить сложность без жаргона. Это облегчает ревью, тестирование и решение о том, оправдана ли оптимизация дополнительной сложностью.

Паттерны, которые делают сгенерированную ИИ логику читаемой

Читаемая логика приложения редко про красивый синтаксис. Речь о том, чтобы следующее лицо (часто — вы в будущем) поняло код с одного взгляда. При использовании ИИ несколько паттернов стабильно дают результат, который остаётся понятным после снижения новизны.

Держите функции маленькими и с одной ответственностью

ИИ склонен «полезно» упаковывать в одну большую функцию валидацию, трансформацию, сохранение и логирование. Наставляйте модель на меньшие блоки: одна функция — валидация входа, другая — вычисление результата, третья — сохранение.

Полезное правило: если вы не можете описать работу функции коротким предложением без «и», вероятно, она делает слишком много.

Предпочитайте явный контроль потока

Читаемая логика легче воспринимается через очевидные ветвления, чем через хитрые компрессии. Если условие важно, напишите его в виде явного if‑блока, а не вложенного тернарного оператора или цепочки булевых трюков.

Когда видите вывод ИИ вроде «всё в одном выражении», попросите «ранние return» и «guard clauses». Это часто уменьшает вложенность и делает счастливый путь видимым.

Называйте вещи так, чтобы коллега смог поддерживать

Осмысленные имена лучше «универсальных хелперов». Вместо processData() или handleThing() предпочитайте имена, кодирующие намерение:

• calculateInvoiceTotal()
• isPaymentMethodSupported()
• buildCustomerSummary()

Также остерегайтесь слишком общих утилит (например, mapAndFilterAndSort()): они могут скрывать бизнес‑правила и усложнять отладку.

Комментируйте намерение, а не механику

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

Если коду требуется много комментариев, рассматривайте это как сигнал упростить структуру или улучшить имена — а не добавлять больше слов.

Выбор проектных решений, сохраняющих простоту

Простота редко означает «писать как можно меньше кода». Это писать код, который коллега сможет уверенно изменять через неделю. ИИ может помочь в этом, если вы направите его к решениям, сохраняющим форму решения понятной.

Начинайте с самой простой структуры данных, которая работает

ИИ часто прыгает к хитрым структурам (мапы карт, кастомные классы, вложенные generic‑типы), потому что они выглядят «организованно». Воздержитесь. Для большинства логики приложения простые списки/объекты читаются легче.

Если у вас небольшой набор элементов, список с явным фильтром/поиском чаще читабельнее, чем преждевременное создание индекса. Вводите map/dictionary только тогда, когда поиск — центральная и повторяющаяся операция.

Ограничьте уровень абстракций до тех пор, пока есть повторяемая потребность

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

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

Предпочитайте композицию глубокому наследованию

Деревья наследования усложняют ответ на вопрос: «Откуда пришло это поведение?» Композиция держит зависимости видимыми. Вместо class A extends B extends C отдавайте предпочтение маленьким компонентам, которые комбинируются явно.

В подсказке к ИИ можно прямо написать: «Избегать наследования, если нет стабильного общего контракта; предпочитать передачу хелперов/сервисов как параметров».

Используйте знакомые паттерны, которые понимает ваша команда

ИИ может предложить паттерны, технически корректные, но культурно чуждые вашей кодовой базе. Знакомость — это фича. Просите решения, которые соответствуют вашему стеку и соглашениям (нейминг, структура папок, обработка ошибок), чтобы результат естественно вписывался в ревью и поддержку.

Производительность без ущерба для читаемости

Работа над производительностью идёт в тупик, если вы оптимизируете не то. Лучший «быстрый» код — это обычно правильный алгоритм, применённый к реальной проблеме.

Выберите алгоритм прежде, чем тюнинговать

Прежде чем править циклы или придумывать хитрости, убедитесь, что подход разумен: hash map вместо повторных линейных поисков, set для проверок на вхождение, один проход вместо многих. При запросе к ИИ будьте конкретны: ожидаемый размер входа, сортированы ли данные, что значит «достаточно быстро».

Простое правило: если сложность неправильна (например, O(n²) на больших списках), никакая микрооптимизация вас не спасёт.

Сначала измеряйте (на реальных объёмах)

Не догадывайтесь. Используйте базовое профилирование, лёгкие бенчмарки и — главное — реалистичный объём данных. Сгенерированный ИИ код может выглядеть эффективным, но скрывать дорогую работу (повторный парсинг, лишние запросы).

Документируйте, что и зачем вы измеряли. Короткий комментарий вроде «Оптимизировано для 50k элементов; предыдущая версия таймаутилась на ~2s» помогает следующему инженеру не откатить улучшение.

Оптимизируйте только горячие пути

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

Аккуратно используйте кэширование, батчинг и индексацию

Эти техники даёт большой выигрыш, но добавляют ментальную нагрузку.

• Кэширование: записывайте правила инвалидации и TTL в комментарии рядом с кодом.
• Батчинг: объясняйте размер батча и обработку ошибок.
• Индексация: указывайте, какие запросы выигрывают и какая цена на запись.

Если ИИ предлагает любое из этих решений, попросите объяснить «почему», компромиссы и когда убрать оптимизацию.

Тестирование — страховочная сетка для сгенерированной ИИ логики

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

Просите тесты одновременно с кодом

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

Практическое разделение:

• Unit‑тесты для чистых бизнес‑правил (цены, проверки права, валидации)
• Интеграционные тесты для «клейкой» логики (запросы к БД, очереди, HTTP), с использованием фейков или тестовых контейнеров

Покрывайте крайние случаи, которые ИИ часто пропускает

ИИ склонен писать «happy path» первым. Сделайте крайние случаи явными в плане тестирования, чтобы потом не полагаться на память или устную передачу знаний. Частые случаи:

• Пустые входы, отсутствующие поля, null / undefined
• Неожиданные типы или некорректные данные
• Таймауты, повторные попытки, частичные сбои (особенно в сетевых вызовах)
• Идемпотентность (безопасные повторы) и дублирующиеся события

Используйте табличные или property‑тесты для бизнес‑правил

Бизнес‑логика часто имеет много небольших вариаций («если пользователь X и заказ Y, то Z»). Табличные тесты держат это читаемым, перечисляя входы и ожидаемые выходы в компактной матрице.

Если правило имеет инварианты («итог не может быть отрицательным», «скидка не превышает подытог»), property‑тесты помогут проверить гораздо больше случаев, чем вы бы написали вручную.

Тесты защищают рефактуры и оптимизации

С хорошим покрытием вы сможете безопасно:

• Заменять вложенные услови на более понятные структуры
• Кэшировать или батчить вызовы для производительности
• Выносить хелперы без изменения поведения

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

Контроль ревью для ИИ‑написанной логики приложения

ИИ может сгенерировать «правдоподобный» код, который чисто выглядит. Хорошее ревью фокусируется не на том, могли ли вы так написать код, а на том, соответствует ли он требованиям и архитектуре приложения.

Быстрый чек‑лист

Используйте это как быстрый первый проход перед обсуждением стиля или микрооптимизаций:

• Корректность: Соответствует ли требованиям и крайним случаям (пустые входы, null, дубликаты, часовые пояса, округление)? Ошибки обработаны намеренно?
• Ясность: Сможет ли коллега объяснить поток после одного чтения? Имена конкретны (например, isEligibleForDiscount vs flag)?
• Сложность: Логика сложнее, чем нужно (глубокие условные конструкции, хитрые однострочники, преждевременные абстракции)?
• Дублирование: Не повторился ли код в ветках, который можно централизовать?

Следите за скрытой сложностью

ИИ часто «решает» задачи, закапывая сложность в местах, которые легко пропустить:

• Магические числа и строки: Замените константами или enum’ами и добавьте комментарий, если причина неочевидна.
• Неочевидное состояние: Остерегайтесь мутации общих объектов, обновления переменных в разных ветках или зависимости от неявных дефолтов.
• Побочные эффекты: Проверьте логирование, сетевые вызовы, записи в БД или глобальные конфигурации внутри хелперов, которые выглядят как «чистые».

Последовательность важнее хитрости

Убедитесь, что вывод соответствует соглашениям проекта (линтер, структура файлов, типы ошибок). Если нет — исправьте сразу; несоответствие стилю делает будущие рефакторы медленнее и ревью сложнее.

Решите: оставить или переписать вручную

Оставляйте сгенерированную логику, когда она прямая, тестируемая и соответствует договорённостям команды. Переписывайте, когда:

• намерение неочевидно (нужны комментарии, чтобы понять)
• контроль потока запутан (флаги, ранние возвраты повсюду, глубокая вложенность)
• «универсальные» абстракции не подходят домену

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

Соображения безопасности и надёжности

Когда ИИ генерирует логику приложения, он часто оптимизирует «happy path» и оставляет пробелы там, где живут безопасность и надёжность: крайние случаи, режимы отказа и удобные, но небезопасные дефолты.

Не раскрывайте секреты (в промптах и логах)

Обращайтесь с промптами как с комментариями в публичном репозитории. Никогда не вставляйте API‑ключи, продакшн‑токены, данные клиентов или внутренние URL. Следите за выводом: ИИ может предложить логирование полных запросов, заголовков или объектов исключений, содержащих креденшелы.

Правило простое: логируйте идентификаторы, а не полезную нагрузку. Если нужно логировать payload для отладки — редактируйте по умолчанию и включайте через флаг окружения.

Валидируйте входы и предсказуемо падайте

Сгенерированный ИИ код иногда предполагает корректность входов. Делайте валидацию явной на границах (HTTP‑обработчики, консьюмеры сообщений, CLI). Преобразуйте неожиданные входы в предсказуемые ошибки (например, 400 vs 500) и делайте повторы безопасными через идемпотентность.

Надёжность — это ещё про время: добавляйте таймауты, обрабатывайте null и возвращайте структурированные ошибки вместо расплывчатых строк.

Остерегайтесь небезопасных дефолтов

Генерация кода может включать удобные ярлыки:

• Широкие права (например, wildcard IAM‑роли, «admin» scope)
• Слабая криптография (самописные хэши, устаревшие алгоритмы, отсутствие соли)
• Отсутствие проверок авторизации (доверие пользовательским ID)

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

Требуйте указания предположений по безопасности и режимов ошибок

Практичный шаблон запроса: «Объясни предположения по безопасности, модель угроз и что происходит при отказе зависимостей». Вы хотите, чтобы ИИ заявил: «Этот эндпоинт требует аутентификации», «токены ротируются», «таймауты БД возвращают 503» и т. п.

Если эти предположения не соответствуют реальности — код неверен, даже если он быстрый и читаемый.

Поддерживаемость со временем: когда рефакторить, а когда остановиться

ИИ может быстро сгенерировать аккуратную логику приложения, но поддерживаемость зарабатывается месяцами: изменчивые требования, новые коллеги и неравномерный рост трафика. Цель не в бесконечном «совершенствовании» кода — цель в том, чтобы он оставался понятным и продолжал удовлетворять реальные потребности.

Рефакторьте, когда трение измеримо

Рефактор оправдан, когда вы можете указать явную стоимость:

• Фича занимает заметно больше времени из‑за запутанной логики или дублирования
• Баги концентрируются вокруг одного модуля из‑за неясных обязанностей
• Работы по производительности блокируются, потому что код скрывает, где тратится время

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

Документируйте «почему», а не только «что»

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

• зачем оптимизировали участок (что было медленным)
• зачем вынесли абстракцию (что менялось часто)
• почему оставили простой подход (сложность не окупалась)

Храните это рядом с кодом (docstring, README или короткая заметка в /docs) и ссылайтесь на тикеты, если они есть.

Добавьте лёгкие диаграммы для критичных потоков

Для нескольких ключевых путей простая диаграмма предотвращает недопонимания и уменьшает риск случайных переписок:

Request → Validation → Rules/Policy → Storage → Response
                 ↘ Audit/Events ↗

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

Захватите «известные лимиты» и план рефактора

Опишите эксплуатационные ожидания: пороги масштаба, ожидаемые узкие места и следующий шаг. Пример: «Работает до ~50 запросов/с на одном инстансе; узкое место — оценка правил; следующий шаг — кэширование».

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

Практический рабочий цикл, чтобы сохранять ИИ‑вывод быстрым и понятным

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

Здесь же важны инструменты. Если вы используете платформу в стиле Koder.ai (chat‑to‑app с режимом планирования, экспортом исходников и снимками/откатом), те же принципы применимы: получите простую, читаемую первую версию логики приложения, затем итеративно улучшайте её небольшими, ревьюируемыми изменениями. Платформа может ускорить набросок и скелет, но команда всё ещё владеет компромиссами.

Стандарты команды (задайте их перед запросом)

Опишите несколько дефолтов, чтобы каждое ИИ‑сгенерированное изменение начиналось с одинаковых ожиданий:

• Ограничения сложности: предпочитать функции ~40–60 строк; избегать глубокой вложенности; держать низкую цикломатическую сложность (например, «никаких функций с >10 ветвлениями без обоснования»).
• Нейминг: доменные термины вместо технических; никаких сокращений; одиночные буквы только в коротких циклах.
• Цели покрытия тестами: минимальные ожидания (например, «новая логика должна иметь unit‑тесты для happy path + ключевых крайних случаев»).
• Границы оптимизации: оптимизируйте только при наличии доказательств (медленный эндпоинт, горячий цикл или измеряемая регрессия).

Генерируй → ревьюй → измерь → уточняй

1. Опишите фичу и ограничения (входы, выходы, инварианты, обработка ошибок).

2. Попросите у ИИ простую реализацию и тесты.

3. Ревью на предмет ясности перед хитростями. Если вы не можете объяснить в нескольких предложениях — скорее всего слишком сложно.

4. Измерьте только релевантные части. Запустите быстрый бенчмарк или добавьте лёгкое тайминг‑измерение вокруг подозреваемого узкого места.

5. Уточняйте с узкими подсказками. Вместо «сделай быстрее» попросите «уменьшить аллокации в этом цикле, сохранив структуру функции».

Практическое DO/DO NOT

• Делайте: просите маленькие, композиционные функции с ясными именами.
• Делайте: требуйте примеры входов/выходов и тесты в одном ответе.
• Делайте: просите комментарии только там, где «почему» неочевидно.
• Не делайте: принимайте микрооптимизации без измерений.
• Не делайте: позволяйте «магическим» хелперам или абстракциям, которые нигде больше не используются.
• Не делайте: мёржите ИИ‑код, который никто в команде не в силах поддержать.

Переносимый шаблон запроса (копировать/вставить)

You are generating application logic for our codebase.

Feature:
- Goal:
- Inputs:
- Outputs:
- Business rules / invariants:
- Error cases:
- Expected scale (typical and worst-case):

Constraints:
- Keep functions small and readable; avoid deep nesting.
- Naming: use domain terms; no abbreviations.
- Performance: prioritize clarity; optimize only if you can justify with a measurable reason.
- Tests: include unit tests for happy path + edge cases.

Deliverables:
1) Implementation code
2) Tests
3) Brief explanation of trade-offs and any performance notes

(Шаблон оставлен на английском как удобный копируемый фрагмент.)

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