Разработка с AI
Пределы AI: когда не доверять нейросети
Лучший хирург знает, когда НЕ оперировать. Лучший пилот знает ограничения автопилота. Лучший инженер знает, когда AI помогает - и когда создаёт иллюзию работы при реальном риске. Эта разница - между профессионалом и человеком с инструментом.
- Microsoft в 2023 исследовании показал: 40% разработчиков принимают AI-предложения не читая их тщательно.
- В Security-чувствительном коде это создаёт реальные уязвимости.
- «AI overreliance» — новая категория software risk в OWASP.
Предварительные знания
Галлюцинации и ложная уверенность
**Галлюцинация** - AI генерирует правдоподобный, но фактически неверный ответ с высокой уверенностью. В отличие от «не знаю», AI говорит несуществующий факт так же уверенно, как реальный. Это фундаментальное свойство языковых моделей, не баг который будет исправлен.
**Особая опасность: security библиотеки.** AI может галлюцинировать несуществующие npm-пакеты с security функциями. Атакующие создают пакеты с такими именами заранее (typosquatting). Случай 2023: AI рекомендовал npm-пакет, которого не существовало, атакующие создали его с malware. Всегда проверяй пакеты перед установкой.
AI предлагает использовать функцию из библиотеки, которую вы не можете найти в официальной документации. Что делать?
Knowledge Cutoff и отсутствие контекста
**Knowledge cutoff** - дата, до которой AI обучен. После неё: новые версии библиотек, security patches, deprecated APIs, изменения в стандартах - AI не знает. **Отсутствие контекста** - AI не знает вашу кодовую базу, бизнес-логику, архитектурные решения принятые командой.
**Лайфхак с context window:** современные AI (Claude, GPT-4) имеют большое context window. Давайте им релевантный код, документацию, ADR файлы прямо в промпт. AI с контекстом значительно точнее AI без контекста. Инвестиция 5 минут на подготовку контекста экономит часы отладки.
AI дал ответ о новой версии библиотеки, выпущенной 2 месяца назад. Насколько ему можно доверять?
Когда НЕ нужно использовать AI
AI - мощный инструмент, но не для всего. Знание когда НЕ использовать AI так же важно, как знание когда использовать. Неправильное применение создаёт false confidence, технический долг и security риски.
**Практическое правило:** чем выше стоимость ошибки - тем меньше доля AI в решении и больше доля human review. Security critical = human-first. Boilerplate CRUD = AI-first. Бизнес-логика = AI для скаффолдинга, human для логики. Архитектурные решения = AI для brainstorming, human для принятия.
Вам нужно реализовать хранение PII (личных данных пользователей) с шифрованием. Как использовать AI?
Ключевые идеи
- Галлюцинации — системное свойство LLM, не баг: AI уверенно говорит неверные факты
- Knowledge cutoff: всё что новее 6-12 месяцев — проверяй в официальной документации
- Отсутствие контекста: давай AI ваш код, ADR, conventions явно в промпт
- Применимость AI: высокая для boilerplate/алгоритмов, низкая для security/crypto/domain logic
- Стоимость ошибки = уровень AI доверия: чем выше риск — тем больше human review
- Никогда: архитектурные решения без review, crypto primitives, compliance-код без аудита
Завершение курса AI Development
Вы прошли путь от введения в AI-assisted разработку до понимания её пределов. Ключевой вывод: AI - leverage инструмент. Он усиливает то, что у вас уже есть. Слабый инженер с AI = быстрее пишет плохой код. Сильный инженер с AI = экспоненциальный рост продуктивности.
- Рефакторинг с AI — Revisit с новым пониманием пределов: где AI надёжен, а где нужен особый контроль
Вопросы для размышления
- Вспомните случай, когда AI дал вам неверный технический ответ. Как вы это обнаружили? Что было бы, если бы не обнаружили?
- Составьте личный «AI usage policy» для вашей работы: для каких задач AI-first, для каких human-first, для каких AI запрещён?
- Как меняется роль инженера, когда AI берёт на себя всё больше рутинного кода? Какие навыки становятся более, а какие менее ценными?