ИИ в коде часто ловит не баг, а неверный уровень решения.

ИИ в коде часто ловит не баг, а неверный уровень решения.

Сценарий простой: вы просите сгенерить фичу, получаете рабочий фрагмент, но он отвечает не на ту задачу. Формально код запускается. По факту — в проекте появляется лишняя сложность, костыли и техдолг.

3 типовых кейса из веба:
— импорт товаров из Excel: ИИ может собрать парсер, но пропустить нормализацию полей, валидацию и разбор кривых форматов;
— мобильное меню на MODX: вместо лёгкой правки шаблона выдаёт отдельный компонент, который потом надо поддерживать;
— Schema.org: генерит разметку, но без проверки типов, вложенности и валидности в search console.

Вывод для технаря простой: сначала фиксируем уровень решения — шаблон, модуль, компонент, отдельный сервис. Потом уже просим код. Иначе ИИ оптимизирует не архитектуру, а ваш будущий дебаг 🔧

Правильный порядок работы:
1) формулируем цель;
2) определяем слой изменений;
3) задаём ограничения;
4) только потом генерим реализацию.

ИИ полезен, когда его используют как исполнительный инструмент. Если сразу отдавать ему архитектурное решение — получите быстрый ответ и долгий ремонт.