LLM в разработке — что может и не может
LLM училась на массовом плохом коде. Она хорошо жонглирует паттернами из Java/C#, но не понимает особенностей JS и редких функциональных идиом. AI = автоматизация, а не замена разработчика.
Суть
LLM генерирует код проекцией обучающих данных. Корпус — массовый, не очень качественный код. Поэтому в типовых задачах работает хорошо, в нестандартных JS-идиомах и ФП проваливается. AI = очередной инструмент, как IDE, Docker, CI/CD.
Что LLM умеет
- Сгенерировать boilerplate за секунды
- Дать имя переменной/функции
- Объяснить чужой код
- Подсказать алгоритм (Дейкстра за 5 секунд)
- Жонглировать паттернами GoF и SOLID
- Знать абстрактные структуры данных и интерфейсы
- Понимать паттерн Strategy через интерфейс + реализации
Что LLM делает плохо
- Функциональное программирование на JS — мало корпуса
- Замыкания как конструктор — пишет на синтаксисе ООП
- Динамическая генерация callback'ов на замыканиях
- Адаптация GoF под идиомы JS — переносит Java-паттерны буквально
- Понимание идеи — игнорирует подробное ТЗ, делает шаблонный ObjectPool
- Оптимизация под V8 — добывает энтропию из timestamp, ловит processID
Три стратегии работы с LLM
- Однострочный промпт — даёт типовое решение, часто плохое
- Диалог step-by-step — лучше, но медленно
- Полное ТЗ на страницу — нормальное качество, но писать ТЗ дольше, чем писать код руками
Кейс: генератор уникальных ID
- Самописный генератор: ~9-10 млн ID/сек
- UUID v4 на C++: ~5-7 млн ID/сек
- AI делает glue из processID, timestamp и
randomBytes - Не понимает, что
crypto.randomFillSyncпачкой быстрее - Не понимает битовую маску
& 0x3fвместо% 64
Кейс: рефакторинг монад (Cursor)
- Дал AI код в IO-стиле и попросил убрать литерал объекта
- Cursor сделал примеси (mixin), которые автор не любит
- Дублировал логику
run - Не понял сигнатуру
move(-5, 10)без объекта - «На Haskell он бы справился — там корпуса больше»
Цена коммуникации с AI
«Пока я ему втираю, как это правильно написать, я бы десять раз уже написал.»
- AI быстрее на типовом, медленнее на нестандартном
- Объяснять иногда дольше, чем писать самому
- Streaming-генерация мешает читать код — он меняется быстрее
Что НЕ убьёт LLM
- Профессия фронтендера/бэкендера (10 лет точно есть)
- Узкая специализация уйдёт — да
- Конкретный фреймворк наизусть — не нужно
- Сигнатуры API — не нужно
- WordPress тоже 15 лет «должен был» убить — не убил
Антипаттерны
- Vibe-кодинг — вставлять то, что AI выдал, не читая
- Верить бенчмаркам AI (он сравнивает с самописными nanoid/cuid, не с C++)
- Доверять источникам энтропии, которые предложила LLM
- Не проверять сгенерированный код
Историческая аналогия
- IDE с автокомплитом → меньше документации
- Tab-комплит в Cursor/VS Code → ChatGPT-чат вместо Google
- Docker и Kubernetes → DevOps пришёл к разработчику
- AI = такая же эволюция, не революция
🎓 Источники
- 🎓 [🧑💻 Программирование на JavaScript с использованием AI — Cursor] · 2025-08-11 · YouTube
- Тезисы: 3 стратегии (промпт/диалог/ТЗ); кейс генератора ID; vibe-кодер не читает код
- 🎓 [💡 Зачем GoF, SOLID, GRASP, если есть AI] · 2025-12-15 · YouTube
- Тезисы: AI делает ObjectPool с 5 классами, не понимает что список = пул; жонглирует паттернами вслепую; не чувствует JS/TS
- 🎓 [🧐 AI Заставляем Cursor рефакторить код на монадах] · 2025-12-07 · YouTube
- Тезисы: ФП на JS LLM не знает; примеси вместо переписывания; на Haskell бы справилась
- 🎓 [🤷 AI обучен на говнокоде!] · 2025-11-30 · YouTube
- Тезисы: проекция плохого корпуса; «не утонем ли в болоте»; V8 оптимизирует под Facebook/Twitter, остальной код страдает
- 🎓 [🙋 Будет ли существовать профессия фронтендер в мире с LLM] · 2025-12-06 · YouTube
- Тезисы: 10 лет профессия точно; узкая специализация уйдёт; зубрить API не нужно