Я строю метаболический ИИ. Не ту игрушку, которая предсказывает цену биткоина, а симулятор клеточного метаболизма, где тысячи реакций переплетены в циклические сети. Думал, Claude Code с его 200k контекста и хвалёным умением писать код спасёт. Спас он, конечно, мои пальцы от набора бойлерплейта. Но когда дошло до дела — система развалилась. Причём не из-за ошибок в синтаксисе, а из-за фундаментальных архитектурных ограничений, которые Claude Code не видит и не может обойти.
Вот пять ловушек, в которые он упорно попадает. И которые стоили мне двух недель дебага после того, как я доверился «всемогущему» агенту.
Ловушка №1: Контекстная амнезия — память как решето
Claude Code гордится огромным окном, но это окно — не память. Это скорее стопка бумаги на столе. Когда вы работаете над метаболической сетью, где изменение константы скорости одной реакции меняет динамику всей системы через 15 шагов симуляции, агент просто забывает, что он там понаписал.
Вот как это выглядит. Я даю задание: «Напиши класс симуляции метаболического пути с обратной связью». Claude Code выдаёт красивый код с 10 модулями. Через 50 строк он уже не помнит, что в модуле A он определил фермент как константу, а в модуле B — как переменную. Система компилируется, но результаты — чушь.
В разборе того, почему LLM понимают цель, но игнорируют её, это объясняется отсутствием механизма долгосрочного удержания зависимостей. Claude Code не «забывает» — он просто не строит мысленную модель всей системы. Он видит задачу линейно: написал кусок, забыл, пошёл дальше.
Лечение? Не давайте ему писать модули последовательно. Давайте законченный фрагмент с явными перекрёстными ссылками. И проверяйте каждую архитектурную константу вручную.
Ловушка №2: Линейный тупик — мир не последовательный
Метаболическая сеть — это не цепочка вызовов f(x) -> g(x). Это цикл, где выход одного узла подаётся на вход другого, потом возвращается обратно. А Claude Code упорно пишет код так, будто порядок вычислений не важен.
Пример: он генерирует функцию обновления концентраций метаболитов, вызывая их по порядку. Но в реальности все обновления должны быть синхронными — на основе состояния до шага. Если обновить метаболит A, а потом использовать его новое значение для метаболита B, это уже не симуляция, а лажа.
Claude Code выберет простой последовательный цикл, потому что в его тренировочных данных так написано в 90% учебников. Но для сложного ИИ это катастрофа.
В архитектуре LoopCoder показано, как повторяющиеся слои генерируют код, но не понимают глобальной динамики. То же самое здесь: Claude Code создаёт локально правильные строки, но глобально — чушь.
Решение: дайте агенту короткое спецификацияное требование «использовать два массива: старый и новый». Или, ещё лучше, пропишите архитектурный принцип прямо в CLAUDE.md. Без этого он всегда будет скатываться к последовательному обновлению.
Ловушка №3: Батч vs Тик — проклятие дискретности
В метаболическом симуляторе время течёт непрерывно. Но Claude Code обожает дискретные шаги с фиксированным dt. Игнорирует, что при жёстких системах (stiff systems) такой подход даёт численную нестабильность. Когда я попросил написать решатель для системы диффуров, агент выдал простой Эйлер. Даже не упомянул, что для моей задачи нужен неявный метод.
Почему? Потому что в корпусе текстов по биологии фигурируют в основном «игрушечные» модели. Claude Code не способен сам определить, какой метод численного интегрирования подходит для конкретной жёсткости. Он делает батч — сразу все шаги одним способом. А нужно — тик за тиком, адаптивно.
Этот технический долг незаметен на маленьких тестах. Но когда запускаешь симуляцию на 1000 шагов — решение улетает в бесконечность.
В статье про зелёный CI и пустую архитектуру отлично показано, как ИИ-кодинг создаёт долг, который не виден в тестах. У меня CI был зелёным, а симуляция — мёртвой.
Как бороться? Запретите Claude Code самому выбирать решатель. В CLAUDE.md пропишите библиотеки и методы. Или используйте навыковый подход: дайте агенту не задачу, а набор примитивов, из которых он соберёт решение.
Ловушка №4: Эмерджентность под капотом — то, что LLM не видит
Самая коварная ловушка. Claude Code видит систему как сумму правил. Он пишет функцию update_metabolite() — и уверен, что этого достаточно. Но метаболическая сеть — это не сумма. Это эмерджентные свойства: колебания, бифуркации, хаос. Одна и та же сеть с разными начальными условиями ведёт себя кардинально по-разному.
Claude Code не способен предсказать эти эффекты. Он не понимает, что небольшое изменение параметра приведёт к переходу через точку бифуркации. И когда я попросил написать код для анализа устойчивости, он выдал обычную симуляцию без какой-либо проверки седловых точек.
Это не вина агента — это ограничение всей парадигмы LLM. Они не могут строить ментальные модели динамических систем. Они предсказывают следующее слово, а не следующее состояние симуляции.
Выход: не просите Claude Code оценить эмерджентность. Используйте его только для написания отдельных вычислительных ядер, а анализ поведения делайте сами или через отдельные скрипты, которые он же написал под вашим контролем.
Ловушка №5: Иллюзия экспертизы — уверенность без знания
Claude Code пишет код с абсолютной уверенностью. Он не скажет: «Я не уверен, что этот метод численного интегрирования сойдётся». Нет, он выдаст красивые комментарии и псевдооптимизированный код. Но под капотом — выбор устаревшей библиотеки, игнорирование численной стабильности, отсутствие проверок на NaN.
Когда я попросил написать решатель ODE с адаптивным шагом, он использовал scipy.integrate.odeint, который для жёстких систем — смерть. Пришлось объяснять ему, что такое LSODA и зачем нужен odeint только для мягких задач. А ведь я программист, а не математик-численник — я тоже не всё знаю. Claude Code должен был проверить или хотя бы дать вариант с явным указанием метода, но не дал.
В материале о навыковом подходе к промптам описан метод, как заставить агента работать автономно без длинных инструкций — через загрузку конкретных «навыков». Например, скилл «численные методы» с выбором правильного интегратора.
Рекомендация: не верьте готовым решениям от Claude Code. Проверяйте каждую нетривиальную функцию через бумажную спецификацию. И да, придётся учить его правильному инструментарию через системные промпты или отдельные файлы знаний.
Итог невесёлый: Claude Code — отличный клерк. Он напишет CRUD, формочку, даже простенький бэкенд. Но сложный ИИ, где архитектура важнее кода, ему пока не по зубам. Никакой агент не заменит человека, который понимает, почему симуляция разваливается на 500-м шаге. Мой вам совет: используйте Claude Code для компонентов, но архитектуру стройте сами. И обязательно фиксируйте в CLAUDE.md архитектурные ограничения — иначе он перепишет их на свой лад и закопает вас в долги, которые вылезут через месяц.
Время, когда агенты смогут сами проектировать нелинейные системы, ещё не настало. Но, чёрт возьми, работать над этим чертовски интересно.
