Разбор полетов: 4 критические ошибки AI-кодинга и как их избежать, часть 1
Помните историю про Джона? Талантливый предприниматель, который с головой ушел в AI-разработку, но в итоге получил публичный репозиторий с секретами, хаосом в коде и кучей других проблем.
Сегодня я хочу превратить эту историю в практический чек-лист, чтобы вы учились на чужом опыте, а не на своих убытках.
😱 Проблема 1: Публичный репозиторий с секретами
Как было у Джона: В его публичном репозитории валялись .env с кредами от базы данных, private.key и даже захардкоженные в коде логины/пароли. И всё это заботливо закоммитили AI-агенты, которые, как оказалось, не особо парятся о безопасности.
💡 Правильное решение: Автоматизируйте проверку на секреты.
Агенты слепы к контексту безопасности. Они не знают, публичный у вас репозиторий или нет, и что коммитить .env — смертный грех. Это ваша зона ответственности.
Что делать: Внедрите в свой воркфлоу сканер секретов, например, gitleaks. Это инструмент, который можно настроить как pre-commit хук. Он будет автоматически проверять каждый ваш коммит (и коммиты, которые делает агент) на наличие паролей, токенов и ключей. Если что-то найдет — коммит просто не пройдет.
Это часть обязательной «цифровой гигиены», о которой я писал в постах про безопасность. Не доверяйте AI то, что можно и нужно автоматизировать.
🌪 Проблема 2: Мешанина в структуре проекта
Как было у Джона: Монорепа, где на бэкенде все файлы свалены в одну кучу. Никакой структуры, никакой логики. Агент просто создавал файлы там, где ему казалось правильным в данный момент.
💡 Правильное решение: Создайте «карту» для AI.
Решение этой проблемы — это файл AGENTS.MD (или CLAUDE.MD, GEMINI.MD).
Что делать: Прямо в корне репозитория создайте файл, где вы тезисно описываете:
* Структуру проекта: «Все контроллеры лежат в src/controllers, сервисы — в src/services».
* Правила именования: «Файлы именуем в kebab-case, переменные — в camelCase».
* Технологический стек и подходы: «Используем функциональные компоненты React и Hooks. Все эндпоинты следуют RESTful конвенции».
Этот файл — шпаргалка для агента, которую он будет держать перед глазами. Так вы превращаете его из хаотичного «творца» в дисциплинированного члена команды.
часть 2
#ai_coding@the_ai_architect
✔️ The AI Architect Blog, подписывайтесь!
Помните историю про Джона? Талантливый предприниматель, который с головой ушел в AI-разработку, но в итоге получил публичный репозиторий с секретами, хаосом в коде и кучей других проблем.
Сегодня я хочу превратить эту историю в практический чек-лист, чтобы вы учились на чужом опыте, а не на своих убытках.
😱 Проблема 1: Публичный репозиторий с секретами
Как было у Джона: В его публичном репозитории валялись .env с кредами от базы данных, private.key и даже захардкоженные в коде логины/пароли. И всё это заботливо закоммитили AI-агенты, которые, как оказалось, не особо парятся о безопасности.
💡 Правильное решение: Автоматизируйте проверку на секреты.
Агенты слепы к контексту безопасности. Они не знают, публичный у вас репозиторий или нет, и что коммитить .env — смертный грех. Это ваша зона ответственности.
Что делать: Внедрите в свой воркфлоу сканер секретов, например, gitleaks. Это инструмент, который можно настроить как pre-commit хук. Он будет автоматически проверять каждый ваш коммит (и коммиты, которые делает агент) на наличие паролей, токенов и ключей. Если что-то найдет — коммит просто не пройдет.
Это часть обязательной «цифровой гигиены», о которой я писал в постах про безопасность. Не доверяйте AI то, что можно и нужно автоматизировать.
🌪 Проблема 2: Мешанина в структуре проекта
Как было у Джона: Монорепа, где на бэкенде все файлы свалены в одну кучу. Никакой структуры, никакой логики. Агент просто создавал файлы там, где ему казалось правильным в данный момент.
💡 Правильное решение: Создайте «карту» для AI.
Решение этой проблемы — это файл AGENTS.MD (или CLAUDE.MD, GEMINI.MD).
Что делать: Прямо в корне репозитория создайте файл, где вы тезисно описываете:
* Структуру проекта: «Все контроллеры лежат в src/controllers, сервисы — в src/services».
* Правила именования: «Файлы именуем в kebab-case, переменные — в camelCase».
* Технологический стек и подходы: «Используем функциональные компоненты React и Hooks. Все эндпоинты следуют RESTful конвенции».
Этот файл — шпаргалка для агента, которую он будет держать перед глазами. Так вы превращаете его из хаотичного «творца» в дисциплинированного члена команды.
часть 2
#ai_coding@the_ai_architect
