AI-инструменты уже стали частью разработки. Кто-то использует их, чтобы быстрее писать черновики кода. Кто-то просит объяснить ошибку. Кто-то генерирует тесты, документацию, SQL-запросы, регулярки и куски верстки.
И в целом это нормально. Более того, если пользоваться AI с головой, он действительно может ускорять работу и снимать часть рутины.
Проблема начинается в момент, когда разработчик забывает простую вещь: AI — это инструмент, а не ответственный инженер, безопасник, архитектор, юрист и DevOps в одном лице.
Нейронка может уверенно предложить решение. Может красиво объяснить. Может даже написать код, который на первый взгляд выглядит прилично. Но если после этого что-то сломается, данные утекут, прод упадет или клиент потеряет деньги, отвечать будет не AI.
Отвечать будете вы. Ну или ваша команда. Но AI точно не придет на ретро и не скажет: "Да, это я виноват, депремируйте меня".
Поэтому вот список вещей, которые при работе с AI лучше не делать.
1. Не пускайте AI напрямую в прод
Самый очевидный пункт, но пусть будет первым.
AI не должен самостоятельно деплоить код, менять настройки прода, перезапускать сервисы, накатывать миграции или выполнять команды в боевом окружении без контроля человека.
Да, звучит как будто это и так понятно. Но чем удобнее становятся инструменты, тем больше соблазн сказать: "Ну он же сам поправил, пусть сам и применит".
Вот только прод — это не песочница.
AI может неправильно понять задачу, не учесть окружение, перепутать команду, предложить опасную миграцию или просто уверенно сделать ерунду. А последствия будут вполне реальные: упавший сервис, потерянные данные, сломанная оплата, злой клиент и очень интересный вечер.
AI может помогать готовить решение. Но финальное решение о релизе должен принимать человек.
2. Не отправляйте в AI ключи, токены и .env
Если в файле лежат API-ключи, пароли, токены, приватные URL, доступы к базам, секреты платежек или что-то похожее — не надо отправлять это во внешний AI-инструмент.
Вообще.
Даже если "ну мне просто ошибку объяснить". Даже если "я потом удалю". Даже если "там ничего важного". Если это секрет, относитесь к нему как к секрету.
Файл .env — это не учебный пример и не текст для анализа. Это набор доступов, который при неправильном использовании может открыть дорогу туда, куда никого пускать не планировали.
Перед тем как просить AI помочь с конфигом, вычищайте все реальные значения. Оставляйте структуру, названия переменных, примерные заглушки. Этого обычно достаточно, чтобы получить подсказку и не раздать ключи от квартиры, где деньги лежат.
3. Не скармливайте персональные данные пользователей
Логи, дампы, таблицы, ошибки, выгрузки из админки — всё это может содержать персональные данные.
ФИО, телефоны, почты, адреса, платежные данные, токены сессий, внутренние комментарии, ID клиентов, история заказов. Иногда чувствительная информация прячется там, где её вообще не ждешь.
И вот это всё нельзя просто брать и отправлять в AI со словами: "Посмотри, почему у нас тут падает обработка".
Если нужно разобрать ошибку — обезличивайте данные. Заменяйте реальные значения на тестовые. Оставляйте структуру, но убирайте конкретных людей.
Потому что "я хотел только баг починить" — слабое оправдание, если вы случайно вынесли наружу клиентскую базу.
4. Не давайте AI полный доступ к боевой базе
AI с доступом к базе данных звучит удобно. Можно попросить написать запрос, найти проблему, посмотреть статистику, проверить гипотезу.
Но полный доступ к боевой БД — это уже не удобство, а потенциальная катастрофа.
Особенно если там есть персональные данные, платежи, заказы, финансовая информация или любые данные, потеря которых будет больной.
Если очень нужно использовать AI рядом с данными, то безопаснее работать через:
- тестовую базу;
- обезличенный дамп;
- read-only доступ;
- ограниченный набор таблиц;
- заранее подготовленные примеры;
- ручную проверку всех запросов перед выполнением.
И уж точно не надо давать нейронке права на удаление, обновление и массовые изменения в проде. Команда DELETE и бодрый AI-ассистент — сочетание на любителя.
5. Не выпускайте AI-код без проверки
AI-код может выглядеть очень уверенно. Красивые названия переменных, аккуратная структура, комментарии, даже тесты иногда рядом лежат.
Но внешний вид не равен качеству.
Сгенерированный код может:
- не учитывать крайние случаи;
- ломать старую логику;
- быть небезопасным;
- плохо работать на реальных данных;
- использовать устаревший подход;
- проходить простой сценарий и разваливаться на втором шаге.
Поэтому правило простое: AI написал — вы проверили.
Нужны тесты, ревью, локальный запуск, понимание того, что код делает, и нормальная проверка в контексте проекта. Не надо превращать AI в кнопку "сгенерировать и молиться".
6. Не доверяйте AI безопасность вслепую
Авторизация, права доступа, платежи, криптография, SQL, CORS, валидация, работа с файлами, личные кабинеты — это зоны, где ошибка может стоить дорого.
AI может предложить "быстрое решение". И оно даже может работать.
Но "работает" в безопасности — это вообще не главный критерий.
Можно сделать форму логина, которая пропускает не тех пользователей. Можно сделать загрузку файлов, через которую потом прилетит неприятный сюрприз. Можно написать SQL-запрос, который открывает дверь для инъекций. Можно "временно" выключить проверку прав, а потом забыть включить.
Если вы сами не понимаете последствия решения, не надо слепо доверять AI в таких местах. Лучше потратить время, разобраться, спросить более опытного человека или хотя бы несколько раз перепроверить.
7. Не принимайте архитектуру от AI без контекста
AI очень любит рисовать красивые схемы. Сервисы, очереди, кэши, слои, адаптеры, паттерны, микросервисы, CQRS, event-driven, вот это всё.
Иногда это полезно. Но есть нюанс.
AI не живет в вашем проекте. Он не знает всех старых решений, реальных сроков, бюджета, состава команды, уровня разработчиков, нагрузки, бизнес-ограничений и того самого легаси, которое нельзя трогать, потому что "оно держит половину продаж".
Поэтому архитектурные советы от AI нужно воспринимать как черновик для обсуждения, а не как готовую истину.
Хорошая архитектура — это не самая красивая схема. Это решение, которое подходит конкретному проекту, команде, срокам и будущему развитию.
8. Не копируйте код, который не можете объяснить
Очень простой тест: если вы вставили кусок кода из AI и не можете объяснить, что он делает, зачем он нужен и почему он безопасен — этот код не должен ехать дальше.
Неважно, что он выглядит умно.
На ревью, при баге или во время доработки вам придется с этим кодом жить. И фраза "ну это нейронка написала" не сильно поможет.
AI может быть хорошим помощником, но он не снимает с разработчика обязанность понимать собственный код.
Если код слишком сложный — попросите AI объяснить его. Потом проверьте объяснение. Потом упростите. Потом еще раз проверьте. И только после этого думайте, место ли этому в проекте.
9. Не используйте AI как замену мышлению
Это главный пункт, который объединяет все остальные.
AI хорош, когда у вас уже есть голова на плечах. Он может ускорить рутину, предложить варианты, помочь с ошибкой, подсказать направление, объяснить незнакомый кусок кода.
Но если полностью передать ему мышление, получится странная история.
Вы вроде бы быстрее пишете код, но хуже понимаете проект. Быстрее закрываете задачи, но чаще тащите внутрь непроверенные решения. Быстрее получаете ответы, но перестаете задавать нормальные вопросы.
В итоге AI из инструмента превращается в костыль. А костыли, как мы уже знаем, имеют неприятную привычку становиться частью архитектуры.
Если коротко: AI в разработке — это мощный инструмент, но не индульгенция на бездумность.
Пользуйтесь им. Генерируйте черновики. Разбирайте ошибки. Ускоряйте рутину. Но не отдавайте ему ключи, данные, прод, безопасность, архитектуру и собственную голову.
Потому что когда всё пойдет не так, в тикете будет не "AI ошибся". В тикете будет ваша фамилия, ваш коммит и очень неприятный вопрос: "А кто это зарелизил?".
Подписывайтесь на SkylinnTime — https://dzen.ru/skylinntime. Здесь будем говорить про IT, разработку и игровую индустрию без сказок про лёгкие деньги, но и без лишнего нытья. Пишет практикующий Senior Fullstack web developer и teamlead, который всё это видит не только со стороны красивых вакансий.