Разработка с LLM — это не только инженерная, но и **когнитивная дисциплина**. Каждая из пяти ключевых практик AI-assisted development наталкивается на конкретное когнитивное искажение, которое мешает разработчику действовать рационально даже когда он _знает_ правильный подход. Исследование METR 2025 года — рандомизированный контролируемый эксперимент с 16 опытными open-source разработчиками — обнаружило, что использование AI-инструментов замедляло работу на **19%**, притом что сами разработчики были убеждены в ускорении на **20%**. Этот разрыв между восприятием и реальностью - не аномалия, а системный паттерн: за каждым техническим решением стоит психологическая ловушка, превращающая «знать» в «не делать». ## 1. Гигиена контекста: почему вы не перезапускаете сессию, хотя должны: ### Деградация — не баг, а физика модели. Фундаментальное исследование «Lost in the Middle» установило U-образную кривую: **модели лучше обрабатывают информацию в начале и конце контекста**, **существенно теряя качество для данных в середине**. Но проблема глубже, чем позиционный эффект. Исследование 2025 года (arXiv:2510.05381) доказало: **даже при идеальном извлечении всей релевантной информации производительность падает на 13.9–85%** по мере роста длины входа. Деградирует не retrieval, а само рассуждение. Масштабное исследование Chroma Research (июль 2025) протестировало 18 моделей, включая GPT-4.1, Claude 4 и Gemini 2.5, на намеренно простых задачах. Результат: производительность ухудшалась у всех моделей при увеличении контекста, даже на тривиальных задачах вроде повторения слов. Бенчмарк NoLiMa показал, что **11 из 12 моделей падают ниже 50% своей эффективности** уже на 32K токенов — далеко от заявленных лимитов окна контекста. На практике это выглядит так: разработчик описал, что после длинной сессии модель молча переключилась с синхронного `requests` на асинхронный `httpx`, сломав стейджинг. Другой обнаружил, что модель начала генерировать `match/case` синтаксис Python 3.10 после указания таргетить 3.9. Это не драматические галлюцинации — это **микро-дрифт**, который обнаруживается только при запуске всей системы. Документация Claude Code прямо признаёт **20–30% деградацию** при работе с накопленным контекстом. ### Субагентная архитектура как решение. Google ADK показал, что субагенты обрабатывают **на 67% меньше токенов** за счёт изоляции контекста. Система MASAI (Arora et al., 2024) с отдельными субагентами для генерации тестов, воспроизведения багов и редактирования кода достигла **28.33%** на SWE-Bench Lite — лучший результат на момент публикации. HyperAgent с четырьмя специализированными агентами (Planner, Navigator, Code Editor, Executor) показал **31.4%** на SWE-Bench Verified. Антропик обнаружил, что **объём использованных токенов объясняет 80% вариации качества** в их мультиагентной системе — субагенты работают не потому что «умнее», а потому что позволяют потратить токены эффективно, в чистых контекстах. Практические метрики: 3–4 часа работы мидл-разработчика генерируют примерно 50–70K токенов. Claude Code автоматически запускает компактизацию при 75–92% заполнения контекста (из 200K доступных ~140–150K после системного промпта). Cursor ограничивает чат-сессии до ~20K токенов по умолчанию. [Qodo](https://www.qodo.ai/blog/claude-code-vs-cursor/) использует «repo map» — карту файловой структуры вместо полного дампа кодовой базы. ### Когнитивная ловушка: «Я уже слишком много вложил в эту сессию» За нежеланием перезапускать сессию стоит каскад из четырёх когнитивных искажений: **Sunk Cost Fallacy** (Arkes & Blumer, 1985). В эксперименте «невидимый самолёт» 85% участников проголосовали за продолжение провального проекта, когда им сообщали о предыдущих инвестициях, — против 10%, когда информация о затратах отсутствовала. Prospect Theory Канемана и Тверски (1979) объясняет механизм: потери воспринимаются примерно **вдвое болезненнее** эквивалентных выигрышей. Когда разработчик потратил час, объясняя архитектуру модели, перезапуск воспринимается как «определённая потеря» контекста — и мозг предпочитает рисковать с деградировавшей сессией. **Creeping Normality** (Jared Diamond, 2005). Деградация контекста по определению градуальна. В эксперименте участники, которым медленно повышали температуру в комнате с 22°C до 32°C за 20 минут, **не замечали дискомфорта** — в отличие от тех, кого помещали сразу в 32°C. Каждый следующий ответ модели лишь чуть хуже предыдущего, разница ниже порога Just Noticeable Difference. Только когда код ломается катастрофически, разработчик осознаёт накопленную деградацию. **Automation Bias** (Parasuraman & Manzey, 2010). Исследование в радиологии показало: когда AI давал неверные оценки маммограмм, точность обнаружения рака у опытных радиологов падала с ~80% до **45%**, у менее опытных — до **22%**. Модель продолжает генерировать уверенно сформулированный текст вне зависимости от качества контекста — и разработчик продолжает доверять. Исследование Nature Scientific Reports (2023) доказало, что AI-bias **сохраняется в человеческих решениях даже после удаления AI**. **Anchoring Effect** (Kahneman & Tversky, 1974). Первые ответы модели в чистом контексте создают мощный якорь ожиданий. Nourani et al. обнаружили: «Позитивное первое впечатление приводит к automation bias и большему количеству ошибок». Разработчик интерпретирует деградированные ответы через призму начального качества, что требует **значительно большего** падения для осознания проблемы. ### Мост: автоматический разрыв вместо волевого решения. Субагентная архитектура решает проблему не на уровне «надо перезапускать чаще» (что требует волевого преодоления sunk cost), а на уровне **инфраструктуры**: каждая подзадача автоматически получает чистый контекст. Это устраняет необходимость принимать решение о перезапуске — решение уже встроено в процесс. Эмоциональные инвестиции в каждый отдельный контекст минимальны, creeping normality не успевает накопиться, а якорение происходит внутри каждой короткой сессии, где качество стабильно. ## 2. Memory Bank: почему ваш AGENTS.md — это иллюзия полноты ### От монолитного промпта к архитектуре знаний. Концепция Memory Bank зародилась в сообществе Cline (вдохновлённая фильмом «Memento»): агент теряет память при каждом перезапуске, но восстанавливает контекст из структурированных внешних заметок. [cline](https://cline.bot/blog/memory-bank-how-to-make-cline-an-ai-agent-that-never-forgets) Базовая архитектура — папка `memory-bank/` в корне проекта с файлами: `projectbrief.md`, `productContext.md`, `systemPatterns.md`, `techContext.md`, `activeContext.md`, `progress.md`. Ключевая инновация Cline — использование **Mermaid-диаграмм** в системном промпте для описания иерархии файлов и рабочего процесса: формальный язык, однозначный для AI. Roo Code расширил концепцию пятирежимной системой (Architect, Code, Ask, Debug, Test), где каждый режим загружает только релевантный контекст и имеет свои триггеры обновления. Продвинутый вариант (enescingoz/roo-advanced-memory-bank) добавил **Just-In-Time загрузку** — правила подгружаются по запросу, а не все сразу. AGENTS.md — стандарт, поддержанный OpenAI Codex, Cursor, Google Jules и Amp, теперь под управлением Linux Foundation. [Agents](https://agents.md/) Его ключевой принцип: «JIT indexing — предоставляйте пути и glob-паттерны, НЕ полный контент. Маленькие, действенные инструкции вместо энциклопедической документации.» Иерархическая модель: корневой AGENTS.md для универсальных правил, поддиректории для специфичных модулей (nearest-wins). Cursor разделяет **Rules** (статический, всегда-включённый контекст) и **Skills** (динамические возможности, загружаемые по релевантности через `SKILL.md`). Glob-matched rules активируются по паттерну файла: правила тестирования подгружаются только при работе с `*.test.ts`. Это критичная эффективность — по данным практиков, правильное управление контекстом **сокращает время выполнения задачи на 50–70%**. Антропик показал, что для баз знаний до ~200K токенов (~500 страниц) можно включать всё в промпт с prompt caching (снижение задержки в 2+ раза, экономия до 90% стоимости). Для больших баз необходим RAG. Contextual Retrieval от Антропика — добавление объяснительного контекста к каждому чанку перед эмбеддингом — снижает количество неудачных извлечений на **49%**, а в комбинации с reranking — на **67%**. ### Пять когнитивных барьеров на пути к правильной организации знаний: **Cognitive Load Theory** (John Sweller, 1988) — фундамент. Рабочая память может одновременно обрабатывать лишь **2–3 элемента** (Clark, Nguyen, Sweller, 2011; более консервативная оценка, чем классические 7±2 Миллера). Sweller выделяет три типа нагрузки: intrinsic (сложность задачи), extraneous (вызванная плохой организацией информации) и germane (продуктивная обработка). Загрузка всех правил проекта в системный промпт — классический пример **extraneous cognitive load**: правила Python-тестирования нерелевантны при редактировании CSS, но потребляют ёмкость контекстного окна. JIT-загрузка снижает extraneous load, освобождая ёмкость для germane processing. Split-attention effect (Chandler & Sweller, 1991): интеграция разрозненных источников информации ухудшает производительность — монолитный файл с 50+ правилами создаёт именно этот эффект. **IKEA Effect** (Norton, Mochon & Ariely, 2012). Участники были готовы платить **на 63% больше** за мебель, которую собирали сами. Механизм: потребность в компетентности + effort justification + эффект владения. Разработчик, потративший часы на crafting идеального `.cursorrules`, переоценивает его эффективность относительно реального качества. Это создаёт «not invented here» синдром: собственное решение предпочитается объективно лучшему внешнему. **Illusion of Explanatory Depth** (Rozenblit & Keil, Yale, 2002). Люди верят, что понимают сложные системы глубже, чем на самом деле. Иллюзия обнаруживается только при попытке **объяснить** механизм — тогда пробелы становятся очевидны. Разработчик видит свой AGENTS.md с заголовками «Архитектура», «Тестирование», «Конвенции» и думает: «Тут всё есть.» Но когда AI пытается использовать этот файл, обнаруживается масса пропущенного неявного знания: порядок деплоя, обработка ошибок, причины архитектурных решений. **Curse of Knowledge** (Camerer, Loewenstein & Weber, 1989). Эксперт не может реконструировать состояние «незнания». Разработчик, работающий с кодовой базой месяцами, пишет правило «используй стандартную обработку ошибок» — не осознавая, что AI не знает, какой паттерн «стандартный». Bias устойчив к коррекции: ни осведомлённость о нём, ни финансовые стимулы не устраняют эффект. Принцип UX «You are not the user» трансформируется в: **«You are not the AI.»** **Transactive Memory Systems** (Wegner, 1987). Групповая система памяти, где участники коллективно кодируют, хранят и извлекают распределённое знание. Три измерения: специализация, доверие, координация. Memory Bank — это TMS между разработчиком и AI-агентом. Разработчик — «эксперт», кодирующий знания в файлы. AI знает, _где искать_ (какой файл содержит архитектуру vs. прогресс vs. решения). Исследования TMS показывают, что **потеря участника разрушает производительность** — аналогично потере контекста при сбросе сессии. Memory Bank — инфраструктура, переживающая «потерю участника». ### Мост: от «я знаю свой проект» к «проект знает себя сам». IKEA Effect и Curse of Knowledge создают парадокс: чем лучше разработчик знает проект, тем хуже он документирует его для AI, потому что не может увидеть собственные пробелы. Структурированная Memory Bank с отдельными файлами для решений (`decisionLog.md`), паттернов (`systemPatterns.md`) и технического контекста (`techContext.md`) **заставляет** экстернализировать имплицитное знание. Это не просто организация файлов — это **когнитивный протокол**, который систематически противодействует Curse of Knowledge, разбивая размытое «я всё знаю про проект» на конкретные, верифицируемые артефакты. ## 3. Детерминированный Feedback Loop: хирургический чеклист для кода ### AI генерирует в 1.7 раза больше дефектов — и это нормально. Анализ CodeRabbit (470 PR) установил: AI-authored PR содержат **10.83 issue vs. 6.45 у человеческих** — в 1.7 раза больше. Логические ошибки выше в 1.75 раза, проблемы безопасности — в 1.57 раза, алгоритмические ошибки — в **2.25 раза**. Veracode обнаружил, что **45% AI-сгенерированных сэмплов** проваливают базовые тесты безопасности (Java — 72%, JavaScript — 43%). Исследование 576 000 сэмплов кода показало, что **19.7% зависимостей в AI-коде — галлюцинации** (несуществующие библиотеки), причём 43% галлюцинаций повторяются, открывая вектор для «slopsquatting»-атак. Aider первым внедрил автоматический линтинг после каждого AI-редактирования. Система использует **tree-sitter** для парсинга AST и представления ошибок в LLM-friendly формате — с контекстом функции/класса вместо сырых номеров строк (модели «quite bad at working with source code line numbers»). Цикл: код → линтер → ошибка → LLM фиксит → повторный линтинг. Обычно **2–3 итерации** для исправления линт/type-ошибок. Формат `FIX_COMMAND && LINT_COMMAND` решает «свыше 90% предупреждений линтера за один прогон». Claude Code предоставляет систему Hooks — post-save хуки для автоматического запуска линтеров/тайп-чекеров/тестов после каждого AI-редактирования. Exit code 2 блокирует изменения. GitHub Copilot и Cursor **не имеют нативных hook-систем** — валидация требует внешних скриптов или CI-пайплайнов. Генеральный pipeline: Code Generation → Lint/Format (ESLint, Black, ruff) → Type Check (mypy, tsc) → Test Suite (pytest, Jest) → Error Feedback в LLM-friendly формате → Auto-Fix Loop → Human Review. Epoch AI установил: «Производительность на SWE-bench отражает софистикацию scaffold в той же мере, что и возможности модели.» Хороший scaffold увеличивает solve rate **до 20%**. ### Edge-кейс, который убивает пайплайн: бесконечный цикл фиксов Документированная проблема Aider (GitHub issue #1090): когда LLM не может исправить lint-ошибку, цикл становится бесконечным — «it will eat tokens like Pacman will eat dots». Высокая строгость линтинга усугубляет проблему. Другой edge-кейс: **тесты, которые ничего не тестируют**. Ranorex обнаружил в 437 enterprise-реализациях: 23% больше false positive, 31% больше времени на отладку тестов, 18% ниже покрытие. Самовосстанавливающиеся тесты «heal themselves into completely different functionality». Qodo сформулировал: «Когда одна модель генерирует и ревьюит код, она не видит собственных слепых зон. Model bias масштабируется.» ### Когнитивная ловушка: «Код выглядит правильно — значит, работает». **Система 1 vs. Система 2** (Kahneman, _Thinking, Fast and Slow_). Визуальный просмотр AI-кода — активность Системы 1: быстрая, автоматическая, паттерн-матчинг. Код «выглядит правильно» — синтаксически корректный, хорошо отформатированный, с осмысленными именами переменных. Автоматические тесты — аналог Системы 2: медленная, методичная, rule-governed верификация. Канеман: «Предвзятости не всегда можно избежать, потому что Система 2 может не иметь ключа к ошибке. Даже когда сигналы доступны, ошибки могут быть предотвращены только усиленным мониторингом и effortful activity Системы 2.» **WYSIATI** (What You See Is All There Is): при ревью AI-кода разработчик видит синтаксис, но не видит edge cases, concurrency issues или уязвимости безопасности. Данные подтверждают: ручной code review находит **менее 15% функциональных багов**; 75% комментариев касаются стиля и поддерживаемости. Формальные инспекции обнаруживают 60–65% дефектов (Capers Jones, 12 000+ проектов). Только комбинация всех методов приближается к **99%**. **Модель швейцарского сыра** (James Reason, 1990). Несколько слоёв защиты (ломтики сыра) с случайными дырками. Инцидент происходит только когда дыры во всех слоях совпадают. Для AI-кода: Slice 1 — генерация с контекстом/RAG; Slice 2 — линтинг; Slice 3 — type-checking; Slice 4 — тесты; Slice 5 — human review; Slice 6 — CI/CD. Ни один слой не достаточен, но их комбинация делает прорыв маловероятным. **WHO Surgical Safety Checklist** (Haynes, Gawande et al., NEJM 2009). 19-пунктный чеклист, 8 госпиталей, 7 688 пациентов. Результат: **снижение смертности на 47%**, осложнений на **36%**. В экстренной хирургии — **62% снижение смертности**. 93% медперсонала хотели бы использовать чеклист при собственной операции. Гаванде: «Чеклисты должны быть короткими, крайне простыми и тщательно протестированными в реальных условиях.» Lint → type-check → test pipeline — это хирургический чеклист для AI-кода. ### Мост: автоматизация Системы 2 Automation bias (Parasuraman & Riley, 1997) предсказывает: разработчики будут недо-валидировать AI-код, особенно после первоначального периода хороших результатов. Confirmation bias в code review: «под давлением времени ревьюер склонен к быстрому одобрению вместо поиска ошибок». Omission Bias: отсутствие пайплайна валидации воспринимается как «бездействие», а не как активный риск. Детерминированный feedback loop превращает Систему 2 из волевого усилия в **автоматическую инфраструктуру**. Как Гаванде доказал для хирургии: простая, детерминированная, последовательно применяемая верификация превосходит экспертную интуицию. ## 4. Правило 90/10: три часа планирования стоят трёх дней отладки ### Данные не оставляют пространства для интерпретации. Addy Osmani (Google Chrome → Anthropic) описал workflow, который стал de facto стандартом: «Одна типичная ошибка — погружаться в генерацию кода с расплывчатым промптом. Первый шаг — brainstorm детальной спецификации с AI, затем пошаговый план, и только потом код.» Он создаёт **spec.md** (требования, архитектурные решения, модели данных, стратегия тестирования), скармливает его reasoning-модели для генерации плана по milestone, и только затем переходит к генерации. Osmani называет это «водопад за 15 минут». Разработчик, который пропустил этот этап, описал результат: «Несогласованный бардак — дублированная логика, несовпадающие имена методов, отсутствие когерентной архитектуры. Как будто 10 разработчиков работали не разговаривая друг с другом.» GitClear (211 миллионов изменённых строк, 2020–2024) обнаружил: code churn (код, переписанный в течение 2 недель) **почти удвоился** — с 3.1% до 5.7%. Рефакторинг упал с **25% до менее 10%** изменений. Дублированные блоки кода выросли **в 8 раз**. Впервые copy-paste превысил рефакторинг. DORA Report 2025 (Google): AI-adoption коррелирует с **9% ростом багов**, **91% ростом времени code review** и **154% ростом размера PR**. DORA ввёл «rework rate» как пятую core-метрику — специально из-за AI. Ключевая формулировка: **«Скорость без стабильности — это ускоренный хаос.»** Uplevel Data Labs (800 разработчиков): разработчики с Copilot-доступом внесли **на 41% больше багов** без значимого роста throughput. Qodo: «AI coding agents очень хороши в получении правильного кода, но плохо справляются с **правильными архитектурными решениями самостоятельно**.» Только **3.8% разработчиков** сообщают одновременно о низком уровне галлюцинаций и высокой уверенности в шиппинге AI-кода без ревью. ### Стоимость ошибки по Бому и её AI-амплификация. Barry Boehm (Software Engineering Economics, 1981) установил: стоимость исправления дефекта растёт **экспоненциально** от этапа requirements к production — до **100–150x** разницы. NASA подтвердил: исправление после деплоя обходится «более чем в 100 раз дороже, чем на этапе требований и раннего дизайна». С AI-кодом кривая Бома потенциально **круче**: AI-генерированные архитектурные ошибки выглядят правдоподобно (труднее обнаружить), AI генерирует большие объёмы архитектурно-некорректного кода быстро (масштаб ошибки), а «comprehension debt» — новый вид технического долга, где разработчик **не понимает** код, который сгенерировал AI — затрудняет раннее обнаружение. Stripe обнаружил: разработчики тратят **42% рабочей недели** на технический долг и плохой код. До **40% IT-бюджета** уходит на последствия технического долга. Sonar: ~53 000 maintainability issues на миллион строк кода. Каждая из этих метрик усугубляется при генерации без предварительного плана. ### Когнитивная ловушка: пять bias на пути от «планировать» к «генерировать» **Planning Fallacy** (Kahneman & Tversky, 1979). Классический эксперимент Buehler, Griffin & Ross (1994): 37 студентов оценили сроки дипломной работы в **33.9 дней** (средний случай) и **48.6 дней** (худший случай). Фактическое среднее: **55.5 дней** — превышает даже «worst case». Только **29.7%** завершили в предсказанный срок. Механизм: «внутренний взгляд» (inside view) — фокус на уникальных характеристиках проекта вместо сравнения с референсной группой аналогичных проектов. В AI-разработке: разработчик воображает, что AI выдаст правильный код с первой попытки, не закладывая галлюцинации, ограничения контекста и циклы отладки. Результат METR (ожидание +20% vs. реальность -19%) — учебниковое проявление planning fallacy. **Action Bias**. Амазон популяризировал «Bias for Action»: «Многие решения обратимы и не требуют глубокого анализа.» Но в AI-кодинге это **неприменимо** к архитектурным решениям, которые необратимы. Полевое исследование ACM (Chattopadhyay et al., ICSE 2020) обнаружило, что **46–70% действий разработчиков** ассоциированы с каким-либо когнитивным искажением. Action-oriented biases ведут к «преждевременным решениям без рассмотрения релевантной информации или альтернатив». **Hyperbolic Discounting** (George Ainslie). Люди предпочитают $50 сейчас $100 через полгода, но не предпочитают $50 через 3 месяца $100 через 9 — гиперболическая, а не экспоненциальная дисконтирующая функция. Нейрологически: немедленные решения активируют **лимбическую систему**, долгосрочное планирование — **фронтальные доли**. Мгновенная генерация кода AI — немедленное вознаграждение. Отложенные затраты (отладка, рефакторинг, comprehension debt) дисконтируются гиперболически. **Dunning-Kruger Effect** (Kruger & Dunning, 1999). AI-инструменты амплифицируют эффект: джуниор, никогда не проектировавший систему, генерирует работающий код через AI и получает **ложное ощущение компетентности**. Он пропускает планирование, потому что верит, что «AI справляется со сложностью». Код работает для простых случаев, но ломается на масштабе — и разработчику не хватает экспертизы для распознавания архитектурных пробелов. **Mere Urgency Effect** (Zhu, Yang & Hsee, 2018, _Journal of Consumer Research_). Пять экспериментов: люди выбирают **неважные задачи** (с меньшим вознаграждением) вместо **важных** (с большим вознаграждением), когда неважные задачи обладают иллюзией срочности. Это нарушает **принцип доминирования** — объективно худший выбор предпочитается лучшему. Занятые люди **более подвержены** эффекту. Нейтрализуется **напоминанием о результате** в момент выбора. В AI-разработке: «получить код» (срочно, короткий цикл, видимый результат) доминирует над «спроектировать архитектуру» (важно, нет дедлайна, невидимый результат). ### Мост: spec.md как «outcome salience» Zhu et al. доказали: Mere Urgency Effect нейтрализуется, когда участникам напоминают о результате. Spec.md — это материализованный outcome: документ, который делает конечную цель видимой и конкретной _до_ начала генерации. Он также противодействует planning fallacy, принуждая к «внешнему взгляду» — сравнению плана с прошлыми проектами. И разрушает гиперболическое дисконтирование: когда стоимость ошибок прописана в спецификации, отложенные затраты становятся ощутимыми _сейчас_. --- ## 5. Специализация моделей: когда один молоток — не для всех гвоздей ### Ни одна модель не доминирует во всех задачах Бенчмарки 2025 года разрушают миф об универсальной модели. SWE-Bench Verified: **Claude Sonnet 4.5 — 82%**, Claude Opus 4.5 — 80.9%. Aider Polyglot (code editing): **Claude Opus 4.5 — 89.4%**, GPT-5 — 88%, Gemini 2.5 Pro — 82.2%. LiveCodeBench (динамический, устойчивый к contamination): **Kimi K2 Thinking — 83.1%**, Gemini 3 Pro — 79.7%, Grok 3 — 79.4%. BountyBench (кибербезопасность): **Codex CLI — 90% успеха патчей**, но Claude Code — **57.5% успеха эксплойтов** (лучше в offensive). Лидер меняется в зависимости от задачи. Практическая таксономия: reasoning-модели (O3, Claude Opus 4) для архитектуры и сложной отладки; «рабочие лошадки» (Claude Sonnet 4, GPT-5, Gemini 2.5 Pro) для ежедневного кодинга; бюджетные модели (GPT-4o-mini, Haiku, DeepSeek) для бойлерплейта и рутины. Osmani: «Запусти вторую AI-сессию (или другую модель) и попроси _её_ критиковать код первой.» Claude пишет — Gemini ревьюит. ### Edge-кейсы маршрутизации Переключение моделей не бесплатно. Потеря контекста при смене модели внутри разговора. Идентичные промпты дают **принципиально разные результаты** на разных моделях, требуя prompt engineering под каждую. Codex «требовал больше надзора — перезапуск команды часто генерировал альтернативные реализации или реинтродуцировал баги». Builder.io отметил: «У Cursor много опций — классно в теории, но может перегружать на практике.» ### Когнитивная ловушка: «Я знаю свой инструмент — зачем менять?» **Einstellung Effect** (Luchins, 1942). В эксперименте с кувшинами воды участники решали серию задач формулой B - A - 2C. Когда появлялась задача с простым решением A + C, большинство продолжало применять сложную формулу. Когда появлялась задача, решаемая _только_ простой формулой — многие **не справились вовсе**. Bilalić, McLeod & Gobet (2008) провели eye-tracking на шахматистах: эксперты, нашедшие одно решение и утверждавшие, что ищут лучшее, продолжали **фиксировать взгляд на элементах первого решения**. «Первая идея направляет внимание к согласующейся информации и от противоречащей. Этот bias продолжается неосознанно даже когда игроки верят, что ищут альтернативы.» Разработчик, ставший экспертом в ChatGPT, подсознательно продолжает использовать его для задач, где Claude объективно лучше. **Maslow's Hammer**: «Если единственный инструмент — молоток, всё вокруг выглядит как гвоздь.» В AI-разработке: «Когда всё, что у вас есть — ChatGPT, всё выглядит как ChatGPT-задача.» **Choice Overload** (Barry Schwartz, _The Paradox of Choice_, 2004). Experiment Iyengar & Lepper: покупатели, видевшие 6 видов джема, были довольнее выбором, чем видевшие 30. Herbert Simon (1956) ввёл понятие **satisficing** (satisfy + suffice): с учётом времени на принятие решения, satisficing — это и есть максимизирующая стратегия. Schwartz обнаружил, что maximizers (ищущие лучший вариант) имеют **ниже удовлетворённость жизнью**, больше сожалений и тревоги. При 141 000 моделей на HuggingFace и десятках viable coding-моделей разработчики сталкиваются с подлинным choice overload, ведущим к двум дисфункциональным реакциям: параличу (бесконечная оценка вместо работы) или дефолту на знакомую модель вне зависимости от задачи. **Zero-Risk Bias** (связан с Prospect Theory). Люди предпочитают полное устранение одного риска более значимому снижению общего риска. Использование одной модели для всего устраняет риск «выбрать неправильно» — даже когда multi-model routing доказуемо улучшает и качество, и стоимость. ### Мост: satisficing framework как противоядие от Einstellung Решение — не в бесконечной оценке моделей (maximizing), а в **создании правил второго порядка** (satisficing): «O3 для архитектуры, Sonnet для реализации, Haiku для бойлерплейта». Cursor Auto Mode — инфраструктура satisficing: автоматический выбор модели снимает когнитивную нагрузку выбора, сохраняя выгоды специализации. Периодическая (не непрерывная) переоценка правил — как ребалансировка портфеля, а не daily trading. Это противодействует Einstellung Effect, ломая «mental set» через предустановленные правила вместо ad hoc решений. --- ## Заключение: инженерия против природы мышления Пять инсайтов образуют единую модель: **каждая оптимальная инженерная практика AI-разработки блокируется конкретным когнитивным искажением**. Sunk Cost Fallacy мешает гигиене контекста. IKEA Effect и Curse of Knowledge мешают правильной организации знаний. Automation Bias мешает валидации. Planning Fallacy и Hyperbolic Discounting мешают планированию. Einstellung Effect мешает специализации моделей. Ключевой паттерн решения одинаков во всех пяти случаях: **превращение волевого решения в инфраструктурный дефолт**. Субагенты автоматически изолируют контекст — не надо «решать» перезапустить сессию. Memory Bank заставляет экстернализировать знания — не надо «помнить» что AI не знает. Lint pipeline автоматически проверяет код — не надо «заставлять себя» тестировать. Spec.md материализует план — не надо «преодолевать» action bias. Model routing rules задают выбор заранее — не надо «каждый раз решать» какую модель использовать. Это не случайное совпадение. Канеман показал, что Система 2 не может постоянно контролировать Систему 1 — ресурсы внимания конечны. Поэтому **«знать ≠ делать»**: информированность о bias не устраняет его. Единственная надёжная стратегия — проектирование среды, в которой правильное действие происходит по умолчанию. В когнитивно-поведенческой терапии это называется **behavioral activation** и **environmental design**. В инженерии — **poka-yoke** (защита от ошибок) и **pit of success** (архитектура, где правильный путь — путь наименьшего сопротивления). Лучшие AI-инженерные практики — это не технические рекомендации. Это **когнитивные протезы**, компенсирующие предсказуемые ошибки человеческого мышления.