Скинули в ИИ текст ошибки. Получили поверхностный ответ. Закрыли вкладку. «Этот ваш ИИ – глупый какой-то».Узнали? Согласны?Статья собрана по заметкам из телеграСкинули в ИИ текст ошибки. Получили поверхностный ответ. Закрыли вкладку. «Этот ваш ИИ – глупый какой-то».Узнали? Согласны?Статья собрана по заметкам из телегра

Почему ИИ выдаёт глупый код — и как это исправить

2026/03/17 10:20
5м. чтение
Для обратной связи или замечаний по поводу данного контента, свяжитесь с нами по адресу crypto.news@mexc.com

Скинули в ИИ текст ошибки. Получили поверхностный ответ. Закрыли вкладку. «Этот ваш ИИ – глупый какой-то».

Узнали? Согласны?


Статья собрана по заметкам из телеграм-канала автора.

Откуда берётся разочарование

Первый опыт с ИИ почти у всех одинаков: открыть chatgpt.com, написать вопрос, получить ответ. Модель отвечает связно, но поверхностно. Код не подходит к проекту. Объяснение — как из учебника для начинающих.

Вывод напрашивается сам: «ИИ хорош для болтовни, но не для реальной работы».

Этот вывод неверен. Он возникает, потому что разработчик воспринимает ИИ-инструмент как чат — место, куда пишешь вопросы и читаешь ответы. ChatGPT закрепил этот образ, потому что именно так выглядит его интерфейс.

Профессиональный ИИ-инструмент для разработки работает иначе. Он не отвечает на вопросы — он выполняет задачи. Разница в архитектуре того, что подаётся на вход.


Как устроена система изнутри

Языковая модель (LLM, Large Language Model) выросла из задачи предсказания следующего слова. Она принимает текст и возвращает текст. Это важно зафиксировать: модель работает только с текстом. Картинки, аудио и видео — за рамками этой статьи.

Чтобы с моделью работать, нужны три слоя: клиент, сервер, сама модель.

Клиент — то, что видит разработчик. Сайт chatgpt.com, приложение Claude Desktop, расширение Copilot в VS Code, Claude Code в командной строке.

Сервер разработчику не виден. Он стоит между клиентом и моделью: принимает запрос, обогащает его данными (актуальная дата, результаты поиска, содержимое файлов), отправляет модели, возвращает ответ клиенту.

Модель получает текст и генерирует текст. Некоторые модели "знают" про инструменты (tools) и умеют их вызывать — тогда сервер запускает инструмент, добавляет результат к запросу и отправляет модели снова. Таких итераций может быть сколько угодно.

Профессиональные клиенты для разработки выполняют ту же цепочку, но автоматизируют сбор контекста (prompt, сообщение на вход модели). Клиент сам читает файлы проекта, сам понимает структуру кода, сам решает, какие файлы нужны модели, чтобы понять задачу. Он же применяет изменения, которые модель велела внести. Разработчик ставит задачу — цикл крутится сам.

Это уже не чат. Но ещё и не замена целых отделов.


Почему архитектура решает всё

Языковая модель неограниченна. Одна и та же задача, заданная дважды, даст разный результат. Та же задача на другой модели — снова другой результат. Разные модели, разные клиенты, разные настройки температуры генерации — всё это источники непредсказуемости.

Разработчик, который воспринимает модель как «умного собеседника», получает случайный код. Иногда подходящий, чаще — нет.

Восприятие автора: модель ограничена входом. Чем точнее описан контекст, ограничения и ожидаемый результат — тем предсказуемее выход. Архитектура на входе даёт архитектурный код на выходе.

Этот принцип оформился в подход, который в разных командах называют по-разному. Любимый термин автора — осознанный вайб-кодинг (Spec Driven Development). Суть в трёх шагах: анализ задачи, планирование, реализация. Всё то же самое, что делает инженер вручную, — только описано в виде инструкций для модели.


Три слоя архитектуры

Архитектура запроса строится из трёх вещей.

AGENTS.md и SKILLS

AGENTS.md — файл в корне проекта (названия варьируются от клиента к клиенту: CLAUDE.md, .github/copilot-instructions.md). В нём описывают технический контекст: какой стек используется, какие соглашения приняты в команде, какие решения и почему. Модель читает этот файл при каждом запросе и знает, в каком проекте работает.

Папка SKILLS содержит инструкции для конкретных сценариев (навыки, скилы). Например, навык «написание нового компонента» описывает, как именно команда пишет компоненты: где хранит состояние, как называет файлы, как обращается к серверу. Навык «подключение к серверу» описывает принятый способ работы с API.

Агент — это действие: «составь план», «напиши документацию», «проверь задачу». Навык — это контекст для конкретного типа работы: «написание теста», «работа с формой», «получение данных из внешнего источника». Граница размыта для автора, но логика такая: агент делает, навык знает как.

Протокол контекста модели

MCP (Model Context Protocol) — способ подключить к модели сторонние инструменты. Модель вызывает инструмент, получает результат, продолжает работу.

Примеры: ChromeDevTools MCP открывает страницу, читает HTML, перехватывает HTTP-запросы, собирает логи из консоли. Playwright MCP запускает тесты. GitHub MCP читает и создаёт запросы на слияние. Atlassian MCP получает задачи и документацию из корпоративной базы знаний.

Поток работы

Всё вместе даёт управляемый поток. Агент create-plan.md анализирует задачу и создаёт файл с шагами и контекстом. Агент implement-plan.md берёт этот файл, выполняет шаги по очереди, отмечает завершённые. Если шаг требует написания компонента — подключается нужный навык.

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


Что это даёт

Три конкретных результата:

  • Стабильный формат кода. Модель знает соглашения команды и не изобретает свои.

  • Предсказуемые шаги. Каждый шаг выполнения задачи описан — нет сюрпризов в середине.

  • Независимость от конкретной модели или клиента.


Вывод

ИИ не заменяет инженера. Он усиливает того, кто понимает систему.

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

Cпросите модель «как JS хранит переменные» — получите «по ссылке и по значению». Формально верно. Но если вы знаете, что V8 оптимизирует хранение строк и чисел по-разному, вы зададите другой вопрос — и получите более глубокий ответ.
Cпросите модель «как JS хранит переменные» — получите «по ссылке и по значению». Формально верно. Но если вы знаете, что V8 оптимизирует хранение строк и чисел по-разному, вы зададите другой вопрос — и получите более глубокий ответ.

Раньше с тестами разбирались тестировщики, с бизнес-требованиями — аналитики, с архитектурой — архитекторы. Теперь каждый инженер с языковой моделью охватывает всё это сам. Туда, куда раньше брали троих, сейчас берут одного с правильно настроенными инструментами.

Поэтому понимание основ — JavaScript, React, проектирование систем — не стало менее важным. Оно стало обязательным условием, чтобы вообще получить от модели что-то полезное.

Автор разбирает эту базу в курсах «Грокаем JavaScript» и «Грокаем React», а наблюдения за работой с ИИ публикует в телеграм-канале.

Источник

Отказ от ответственности: Статьи, размещенные на этом веб-сайте, взяты из общедоступных источников и предоставляются исключительно в информационных целях. Они не обязательно отражают точку зрения MEXC. Все права принадлежат первоисточникам. Если вы считаете, что какой-либо контент нарушает права третьих лиц, пожалуйста, обратитесь по адресу crypto.news@mexc.com для его удаления. MEXC не дает никаких гарантий в отношении точности, полноты или своевременности контента и не несет ответственности за любые действия, предпринятые на основе предоставленной информации. Контент не является финансовой, юридической или иной профессиональной консультацией и не должен рассматриваться как рекомендация или одобрение со стороны MEXC.