Ринат Ташев – Вайбкодинг: как зарабатывать в 2026 (страница 6)
Даже в 2026 AI плохо удерживает контекст большого проекта. На 50+ файлах он начинает путать, что где находится.
Поэтому большие проекты требуют человеческой архитектуры с понятной структурой папок и модулей.
8. Внешние интеграции
Когда нужно интегрироваться с конкретным API (особенно нишевым), AI часто галлюцинирует — придумывает endpoints, которых нет, параметры, которые не существуют.
Здесь всегда нужно проверять документацию своими глазами.
Как использовать сильные стороны и обходить слабые
Правило большого пальца:
• Архитектура, решения, безопасность — человек
• Код, документация, тесты, рефакторинг — AI
• Дебаг типовых ошибок — AI
• Дебаг сложных — человек
• Бизнес-логика — человек
• Реализация бизнес-логики — AI
Если делать так — вы получаете 10x продуктивности и сохраняете качество.
Если делать «всё AI» — получаете быстрый старт, но в долгую — багги, уязвимый, плохо архитектурированный продукт. Это типичная ошибка новичков.
Если делать «всё руками» — теряете 10x скорости и проигрываете тем, кто использует AI разумно.
Главное из главы: AI в 2026 — мощный инструмент с конкретными сильными и слабыми сторонами. Сильный в типовом коде, слабый в архитектуре, безопасности и бизнес-логике. Успешный вайбкодер — это человек, который знает, где использовать AI, а где — нет. Не «всё AI» и не «всё вручную».
Глава 6. Безопасность и качество кода
Главные риски AI-generated кода
В 2026 году появилась новая категория ошибок — «AI-generated vulnerabilities». Это уязвимости, которые AI генерирует регулярно, потому что они выглядят правильно, но содержат фундаментальные проблемы.
Топ-7 угроз, которые встречаются чаще всего:
1. SQL Injection
AI часто пишет код, который собирает SQL-запросы конкатенацией строк. Это классическая уязвимость, известная с 1990-х.
Что нужно проверять: всегда используются параметризованные запросы. Никогда не должно быть `SELECT * FROM users WHERE id = ${userId}`.
2. Неправильная аутентификация
AI может сгенерировать аутентификацию, которая «работает» в hello-world, но имеет дыры. Например, JWT-токены без срока действия. Пароли в plain text. Хранение секретов в коде.
Что нужно проверять: хеширование паролей (bcrypt, argon2), JWT с expiration, secrets в env-переменных.
3. XSS (Cross-Site Scripting)
AI иногда вставляет user-input в HTML без эскейпинга. Это позволяет атакующему вставлять JavaScript-код.
Что нужно проверять: все user-input проходят через эскейп. В React/Vue это обычно автоматически, но `dangerouslySetInnerHTML` всё равно опасен.
4. Утечки данных
AI может написать API, который возвращает больше данных, чем нужно. Например, в endpoint'е получения профиля возвращаются password_hash, email, internal_id.
Что нужно проверять: API возвращает только то, что должно быть видно клиенту. Никаких internal-полей.
5. Отсутствие rate limiting
AI обычно не добавляет защиту от перегрузки. Endpoint логина без rate limiting — это приглашение для brute force атак.
Что нужно проверять: критичные endpoints (login, signup, password reset) защищены rate limiting'ом.
6. Незащищённые админ-функции
AI может написать endpoint типа `/api/admin/delete-user`, который доступен без проверки прав. Атакующему достаточно угадать URL.
Что нужно проверять: все админ-endpoints имеют middleware проверки прав.
7. Утечка secrets
AI часто включает api keys, database urls, секретные токены прямо в код. Особенно опасно, если код потом push'ится на GitHub.
Что нужно проверять: ничего секретного нет в коде. Всё в .env. .env в .gitignore.
Базовый чек-лист безопасности
Перед deploy любого приложения проверьте:
Все запросы к базе данных параметризованы (нет конкатенации SQL)
Пароли хешируются (bcrypt/argon2)
Все секреты в .env, не в коде
.env в .gitignore
User-input эскейпится перед выводом
API не возвращает internal-поля
Critical endpoints имеют rate limiting
Авторизация проверяется на каждом защищённом endpoint
HTTPS включён в production
CORS настроен правильно (не allow * в production)
Обновлены все зависимости (npm audit)
Logs не содержат personal data
Если хотя бы один пункт не выполнен — не deploy'те.
Качество кода: что важно, что нет
В вайбкодинге понятие «качество кода» переопределилось. Раньше «качественный код» — это «красивый, оптимальный, элегантный». Сейчас — «работающий, безопасный, поддерживаемый».
Что ВАЖНО в качестве:
• Работает в production
• Безопасный
• Понятный (можно прочитать через 3 месяца)
• Тестируемый
• Документированный (хотя бы базово)