28 мая 2026
180
Вы когда-нибудь просили ИИ написать метод на Spring Boot, получали красивый, идеально отформатированный код, а он не работал? Потом вы копали глубже и находили, что нейросеть использовала RestTemplate вместо WebClient, забыла про @Transactional, а в методе с @PreUpdate пыталась изменить данные, которые уже ушли в SQL. И вы думали: «Ну, нейросеть же глупая». Нет. Не глупая. Она просто пишет код не как человек.
Если привести аналогию, то ИИ — это аниматор промежуточных кадров, а вы — аниматор ключевых кадров. У аниматора промежуточных кадров есть жёсткие ограничения: если ключевых кадров не хватает — он не знает, как дорисовывать; если ключевых кадров слишком много — вы делаете работу за него. С нейросетью — то же самое. Она работает в условиях жёстких ограничений. Если вы их не знаете — будете получать «код-сказку» раз за разом и винить во всём ИИ. А если знаете — получите рабочий код с первой-второй итерации.
В основе этой статьи — многолетняя практика коммерческой разработки экспертов Учебного центра IBS и опыт, который лёг в основу наших курсов по работе с ИИ в реальных проектах. Мы проанализировали сотни кейсов, где ИИ помогал, и где мешал. И пришли к выводу: проблема не в промптах. Проблема в том, что у ИИ есть чёткие, системные ограничения. Их нужно знать — так же, как знать особенности компилятора или JVM.
В этом материале разбираем 6 ключевых ограничений ИИ (плюс один бонус-пример), которые вы обязаны учитывать, если работаете с генерацией кода всерьёз. Сразу уточним: мы используем ИИ каждый день. Но используем его как аниматора, а не как архитектора. Ключевые кадры рисуете вы. ИИ дорисовывает промежуточные. Если ключевых кадров нет — получится ерунда.
Поехали.
Вы замечали, как ИИ в середине диалога начинает предлагать то, что уже обсуждалось? Это ограничение называется «контекстное окно». У нейросети жесткий лимит памяти: она помнит только ограниченный кусок диалога или кода. Всё, что выходило за эти рамки, утрачивается. Вернемся к аналогии с аниматором: если вы дали ему только три ключевых кадра из двадцати, он просто не знает, что рисовать в остальных семнадцати. И чем сложнее задача, тем быстрее ИИ начинает изобретать новые сущности.
Но есть и более жесткое ограничение — невозможная комбинаторика. Исследование Apple показывает: ИИ не способен оперировать больше чем десятью параметрами одновременно. Одиннадцатый параметр — и модель теряет связи между частями решения. На выходе — синтаксически корректный, но полностью нерабочий код. Аниматору дали слишком много деталей в одном кадре — он запутался. С ИИ — то же самое.
Как обойти ограничение: сокращайте контекст. Не давайте ИИ большую задачу, дробите её. Одна итерация — одно изменение. Один запрос — не больше десяти параметров. Используйте микросервисную архитектуру — в ней параметров и связей меньше. И главное — ведите дневник архитектурных решений (ADR), передавая его ИИ перед генерацией. Это дает модели систему координат для создания рабочего кода. ИИ не помнит всё — ваша задача не заставлять его это делать.
Контекстное окно — это то, сколько кода ИИ помнит. Внутренние связи — насколько запутанным этот код может быть. Это разные вещи, и их важно не путать.
У любой программы есть точка, после которой количество внутренних связей становится критическим. Для человека это 2–4 мегабайта кода. Для ИИ этот момент наступает гораздо быстрее. Почему? Аниматор может дорисовать десять связанных объектов в одном кадре, но если каждый из них тянет за собой еще десять связей — он теряет нить. ИИ начинает путаться в собственных решениях, терять связи между модулями и забывать зависимости. Зона комфорта модели — линейные, слабо связанные куски кода. Как только модули начинают активно ссылаться друг на друга — ждите проблем.
Как обойти ограничение: двигайтесь по контуру решения, не проваливаясь вглубь. Не пытайтесь сделать большой рефакторинг или добавить сложную фичу за один раз. Делайте маленький шаг, опираясь на то, что уже работает. Если шаг требует перегенерации большого объема кода — перегенерируйте. Принцип DRY (don't repeat yourself) становится зоной ответственности человека, а не модели. ИИ генерирует линейный код для изоляции ошибок. Рефакторинг и вынос абстракций делает разработчик после прохождения тестов. Код, сгенерированный моделью, ничего не стоит — проще перегенерировать его целиком, даже ради мелкой правки, чем поддерживать чистую архитектуру. Разработка с ИИ — это маленькие улучшения, добавленные поверх существующего кода и покрытые тестами и ADR.
Как обойти ограничение: до начала генерации зафиксируйте архитектурное решение в виде ADR. Этот документ становится частью контекста, и ИИ вынужден учитывать заданные ограничения, а не генерировать произвольные варианты. Также используйте длинные имена переменных и развернутые комментарии — для ИИ они служат рамками, снижающими вариативность ответа. И ключевой прием — прерывающий промптинг. Если вы видите, что модель начинает отклоняться от требуемого курса, остановите её и начните генерацию с уточненными условиями, не позволяя развивать нерелевантные ветки решения.
Как обойти ограничение: требуйте от ИИ максимально линейного, простого кода. Метод в тысячу строк с повторяющимися блоками для ИИ предпочтительнее, чем изящная композиция из десяти маленьких методов.
Вот как это выглядит на практике. Плохо (ИИ пытается быть человеком):
Код красивый, но каждый метод — новая связь. ИИ легко запутается при изменении любого из них.
Хорошо (требуем от ИИ писать как машина):
Не стесняйтесь нарушать DRY. Когда код ничего не стоит (а при генерации через ИИ это именно так), перегенерация длинного линейного фрагмента обходится дешевле, чем отладка связанной системы абстракций. Если вам нужен метод, который обрабатывает два разных сценария, попросите ИИ реализовать их независимо, с дублированием логики. Это изолирует ошибки и позволит перегенерировать проблемный участок целиком, не затрагивая остальной код.
Как обойти ограничение: TDD и BDD перестают быть опциями — они становятся обязательным инструментом. До того как ИИ сгенерирует хотя бы строчку бизнес-логики, вы должны написать тесты. Сценарии, edge-кейсы, негативные сценарии. И только потом отдавать их модели со словами: «сделай, чтобы это работало». Кроме того, тесты должны быть объемными. Не стесняйтесь перегенерировать код вместе с тестами по десять раз, пока все не зазеленеет. Код ничего не стоит, время на перегенерацию — тоже. А вот баг в продвинутой системе с ИИ-кодом обходится очень дорого.
Как обойти ограничение: перед тем как генерировать основной код, создайте работающий прототип на нужной технологии. Маленький микросервис, который делает ровно то, что вы хотите, — использует актуальные версии библиотек и правильные подходы. Этот прототип становится эталоном. Затем добавьте его в контекст ИИ и явно укажите: «генерируй код по образу и подобию этого примера». Нейронка будет опираться на актуальный код, а не на усредненные знания из обучающей выборки. Это требует дополнительных усилий на старте, но на больших объемах генерации окупается многократно.
В JPA существует аннотация @PreUpdate. Её название буквально означает: «вызвать этот метод перед обновлением». Для человека и для ИИ это звучит однозначно: внутри метода можно изменить данные, и эти изменения попадут в базу. Нейросеть сгенерирует код именно так — добавит метод с @PreUpdate, внутри которого спокойно меняет поля сущности, полагая, что обновление ещё не произошло.
В чём ловушка. В реальности SQL для обновления формируется до вызова @PreUpdate. К моменту выполнения метода запрос на обновление уже сформирован. Изменять данные внутри этого метода бессмысленно — они не попадут в выполняющийся SQL.
Как проявляется. Типичный сценарий: в коде встречается метод с @PreUpdate, который должен обновлять поле updatedAt. Тесты проходят, но в продакшене поле не обновляется. Причина: Hibernate формирует SQL до вызова метода. ИИ не «виноват» — он интерпретировал название аннотации буквально, как и человек. Но он и не помог избежать ошибки.
Как обойти: пишите тесты для любого действия. Если сгенерированный метод с @PreUpdate должен что-то менять — напишите тест, который проверяет, что изменения действительно попали в базу после вызова. Тест упадёт, вы увидите проблему и скорректируете код. ИИ не знает и не может знать всех тонкостей работы конкретного фреймворка. Единственный способ защититься — проверять её работу автотестами. Каждый раз.
Но это не значит, что с ИИ нельзя работать эффективно. Можно. Для этого нужно помнить три простых правила:
Первое: дробите задачи. Одна итерация — одна микропроблема. Не больше десяти параметров, не больше десятка связей. Если задача большая — делите её на части и генерируйте последовательно.
Второе: фиксируйте договоренности. ADR, комментарии, длинные имена переменных — всё это становится для ИИ точками опоры. Без них он будет блуждать. С ними — генерировать предсказуемый код.
Третье: проверяйте тестами. TDD при работе с ИИ — защитный механизм. Тест упал — проблема нашлась. Тест прошёл — можно спать спокойно. Без тестов вы никогда не будете уверены, что сгенерированный код действительно делает то, что нужно.
И последнее. Не пытайтесь сделать код красивым. Забудьте про DRY при генерации. Линейный, повторяющийся, примитивный код с огромным количеством комментариев — вот что нужно просить у ИИ. Перегенерировать длинный метод проще, чем отлаживать паутину из десяти связанных абстракций, в которых ИИ запутался на третьем шаге.
ИИ — это инструмент для ускорения написания кода, но не для проектирования. Главные кадры всё равно нужно рисовать вам.
В основе этой статьи — многолетняя практика коммерческой разработки экспертов Учебного центра IBS и опыт, который лёг в основу наших курсов по работе с ИИ в реальных проектах. Мы проанализировали сотни кейсов, где ИИ помогал, и где мешал. И пришли к выводу: проблема не в промптах. Проблема в том, что у ИИ есть чёткие, системные ограничения. Их нужно знать — так же, как знать особенности компилятора или JVM.
В этом материале разбираем 6 ключевых ограничений ИИ (плюс один бонус-пример), которые вы обязаны учитывать, если работаете с генерацией кода всерьёз. Сразу уточним: мы используем ИИ каждый день. Но используем его как аниматора, а не как архитектора. Ключевые кадры рисуете вы. ИИ дорисовывает промежуточные. Если ключевых кадров нет — получится ерунда.
Поехали.
Ограничение №1: контекстное окно и невозможная комбинаторика
Вы замечали, как ИИ в середине диалога начинает предлагать то, что уже обсуждалось? Это ограничение называется «контекстное окно». У нейросети жесткий лимит памяти: она помнит только ограниченный кусок диалога или кода. Всё, что выходило за эти рамки, утрачивается. Вернемся к аналогии с аниматором: если вы дали ему только три ключевых кадра из двадцати, он просто не знает, что рисовать в остальных семнадцати. И чем сложнее задача, тем быстрее ИИ начинает изобретать новые сущности.
Но есть и более жесткое ограничение — невозможная комбинаторика. Исследование Apple показывает: ИИ не способен оперировать больше чем десятью параметрами одновременно. Одиннадцатый параметр — и модель теряет связи между частями решения. На выходе — синтаксически корректный, но полностью нерабочий код. Аниматору дали слишком много деталей в одном кадре — он запутался. С ИИ — то же самое.
Как обойти ограничение: сокращайте контекст. Не давайте ИИ большую задачу, дробите её. Одна итерация — одно изменение. Один запрос — не больше десяти параметров. Используйте микросервисную архитектуру — в ней параметров и связей меньше. И главное — ведите дневник архитектурных решений (ADR), передавая его ИИ перед генерацией. Это дает модели систему координат для создания рабочего кода. ИИ не помнит всё — ваша задача не заставлять его это делать.
Ограничение №2: количество внутренних связей
Контекстное окно — это то, сколько кода ИИ помнит. Внутренние связи — насколько запутанным этот код может быть. Это разные вещи, и их важно не путать.
У любой программы есть точка, после которой количество внутренних связей становится критическим. Для человека это 2–4 мегабайта кода. Для ИИ этот момент наступает гораздо быстрее. Почему? Аниматор может дорисовать десять связанных объектов в одном кадре, но если каждый из них тянет за собой еще десять связей — он теряет нить. ИИ начинает путаться в собственных решениях, терять связи между модулями и забывать зависимости. Зона комфорта модели — линейные, слабо связанные куски кода. Как только модули начинают активно ссылаться друг на друга — ждите проблем.
Как обойти ограничение: двигайтесь по контуру решения, не проваливаясь вглубь. Не пытайтесь сделать большой рефакторинг или добавить сложную фичу за один раз. Делайте маленький шаг, опираясь на то, что уже работает. Если шаг требует перегенерации большого объема кода — перегенерируйте. Принцип DRY (don't repeat yourself) становится зоной ответственности человека, а не модели. ИИ генерирует линейный код для изоляции ошибок. Рефакторинг и вынос абстракций делает разработчик после прохождения тестов. Код, сгенерированный моделью, ничего не стоит — проще перегенерировать его целиком, даже ради мелкой правки, чем поддерживать чистую архитектуру. Разработка с ИИ — это маленькие улучшения, добавленные поверх существующего кода и покрытые тестами и ADR.
Ограничение №3: оптимистичность ИИ (синдром ADHD)
ИИ не умеет говорить «нет». Это следует из самой его природы: он обучен генерировать продолжение диалога и давать релевантные ответы при любых условиях. Аниматору сказали: «нарисуй что-нибудь» — и он нарисует. ИИ поступает так же. Если вы формулируете некорректную задачу или ссылаетесь на несуществующие компоненты, модель не выполнит верификацию и не укажет на ошибку. Вместо этого она начнет развивать предложенное решение, добавляя детали и генерируя правдоподобные, но нерабочие сущности. В результате вы получаете код, который выглядит осмысленно, но не имеет ничего общего с реальной исполняемой средой.Как обойти ограничение: до начала генерации зафиксируйте архитектурное решение в виде ADR. Этот документ становится частью контекста, и ИИ вынужден учитывать заданные ограничения, а не генерировать произвольные варианты. Также используйте длинные имена переменных и развернутые комментарии — для ИИ они служат рамками, снижающими вариативность ответа. И ключевой прием — прерывающий промптинг. Если вы видите, что модель начинает отклоняться от требуемого курса, остановите её и начните генерацию с уточненными условиями, не позволяя развивать нерелевантные ветки решения.
Ограничение №4: попытка работать как человек
ИИ не человек, но он пытается имитировать человеческий стиль написания кода. Когда вы просите его написать сервис, он начинает применять рефакторинг, выносить повторяющийся код в отдельные методы, строить абстракции и следовать принципу DRY. Для человека это правильно. Для нейросети — путь к ошибкам. Аниматор, который вдруг решил, что он режиссер, начнет переписывать сценарий, добавлять новых героев и менять сюжет. Каждая новая абстракция создает дополнительные связи в коде, увеличивает количество параметров, которые нужно контролировать, и повышает вероятность того, что модель запутается. Вместо чистого, поддерживаемого кода вы получаете запутанную систему, в которой ошибка в одном методе тянет за собой цепочку поломок.Как обойти ограничение: требуйте от ИИ максимально линейного, простого кода. Метод в тысячу строк с повторяющимися блоками для ИИ предпочтительнее, чем изящная композиция из десяти маленьких методов.
Вот как это выглядит на практике. Плохо (ИИ пытается быть человеком):
Код красивый, но каждый метод — новая связь. ИИ легко запутается при изменении любого из них.
Хорошо (требуем от ИИ писать как машина):
Не стесняйтесь нарушать DRY. Когда код ничего не стоит (а при генерации через ИИ это именно так), перегенерация длинного линейного фрагмента обходится дешевле, чем отладка связанной системы абстракций. Если вам нужен метод, который обрабатывает два разных сценария, попросите ИИ реализовать их независимо, с дублированием логики. Это изолирует ошибки и позволит перегенерировать проблемный участок целиком, не затрагивая остальной код.
Ограничение №5: отсутствие проверок и тестовой культуры
ИИ генерирует код, который выглядит правильно. Он компилируется, IDE не подчеркивает его красным, структура классов на месте. Но это ничего не значит. Аниматор нарисовал красивую сцену, но забыл, что персонаж должен стоять на земле, а не висеть в воздухе. Нейросеть поступает так же: она не проверяет граничные случаи, не анализирует, что будет, если придет null, если список пуст или если внешний сервис не ответил. Модель генерирует сценарий, в котором всё идеально. В реальном продакшене так не бывает. Отсутствие санити-чеков приводит к тому, что код рассыпается в боевых условиях. И чем больше кода сгенерировано, тем сложнее понять, где именно ИИ забыл про валидацию или обработку ошибок.Как обойти ограничение: TDD и BDD перестают быть опциями — они становятся обязательным инструментом. До того как ИИ сгенерирует хотя бы строчку бизнес-логики, вы должны написать тесты. Сценарии, edge-кейсы, негативные сценарии. И только потом отдавать их модели со словами: «сделай, чтобы это работало». Кроме того, тесты должны быть объемными. Не стесняйтесь перегенерировать код вместе с тестами по десять раз, пока все не зазеленеет. Код ничего не стоит, время на перегенерацию — тоже. А вот баг в продвинутой системе с ИИ-кодом обходится очень дорого.
Ограничение №6: опора на устаревшие данные
ИИ обучается на данных, собранных до определенного момента времени. Для большинства популярных моделей это 2023 год. За это время в экосистеме Java и Spring произошли изменения: одни библиотеки объявили deprecated, другие полностью заменили новыми подходами. Но ИИ этого не знает. Аниматор учился по старым раскадровкам и теперь рисует персонажей в костюмах прошлого сезона. Нейросеть сгенерирует RestTemplate вместо WebClient, потому что в обучающей выборке первого было больше. Он предложит устаревшую конфигурацию Security, использует аннотации, которые больше не работают. Это не ошибка модели в привычном смысле — это опора на статистически релевантные, но устаревшие данные.Как обойти ограничение: перед тем как генерировать основной код, создайте работающий прототип на нужной технологии. Маленький микросервис, который делает ровно то, что вы хотите, — использует актуальные версии библиотек и правильные подходы. Этот прототип становится эталоном. Затем добавьте его в контекст ИИ и явно укажите: «генерируй код по образу и подобию этого примера». Нейронка будет опираться на актуальный код, а не на усредненные знания из обучающей выборки. Это требует дополнительных усилий на старте, но на больших объемах генерации окупается многократно.
Бонус: семантическая ловушка @PreUpdate
Этот пример из реальной практики наглядно иллюстрирует, как ИИ может быть введён в заблуждение самой природой языка.В JPA существует аннотация @PreUpdate. Её название буквально означает: «вызвать этот метод перед обновлением». Для человека и для ИИ это звучит однозначно: внутри метода можно изменить данные, и эти изменения попадут в базу. Нейросеть сгенерирует код именно так — добавит метод с @PreUpdate, внутри которого спокойно меняет поля сущности, полагая, что обновление ещё не произошло.
В чём ловушка. В реальности SQL для обновления формируется до вызова @PreUpdate. К моменту выполнения метода запрос на обновление уже сформирован. Изменять данные внутри этого метода бессмысленно — они не попадут в выполняющийся SQL.
Как проявляется. Типичный сценарий: в коде встречается метод с @PreUpdate, который должен обновлять поле updatedAt. Тесты проходят, но в продакшене поле не обновляется. Причина: Hibernate формирует SQL до вызова метода. ИИ не «виноват» — он интерпретировал название аннотации буквально, как и человек. Но он и не помог избежать ошибки.
Как обойти: пишите тесты для любого действия. Если сгенерированный метод с @PreUpdate должен что-то менять — напишите тест, который проверяет, что изменения действительно попали в базу после вызова. Тест упадёт, вы увидите проблему и скорректируете код. ИИ не знает и не может знать всех тонкостей работы конкретного фреймворка. Единственный способ защититься — проверять её работу автотестами. Каждый раз.
Итоги: как жить с этими ограничениями
Мы разобрали шесть ограничений ИИ и одно бонусное. Если вынести из всего этого главное, то картина выглядит так. ИИ не заменяет архитектора. Он не помнит всё, не умеет комбинировать больше десяти параметров, не скажет «нет», если вы ошиблись, попытается писать как человек, забудет про тесты и будет опираться на старые версии фреймворков. Это не баги. Это специфика технологии.Но это не значит, что с ИИ нельзя работать эффективно. Можно. Для этого нужно помнить три простых правила:
И последнее. Не пытайтесь сделать код красивым. Забудьте про DRY при генерации. Линейный, повторяющийся, примитивный код с огромным количеством комментариев — вот что нужно просить у ИИ. Перегенерировать длинный метод проще, чем отлаживать паутину из десяти связанных абстракций, в которых ИИ запутался на третьем шаге.
ИИ — это инструмент для ускорения написания кода, но не для проектирования. Главные кадры всё равно нужно рисовать вам.