Теория: Кодинг

Этот урок — о том, как использовать ИИ в технической работе. Не только для написания кода, но и для понимания, поиска ошибок, работы с документацией и автоматизации мелких задач.

Чат, Агенты и MCP

Обычно ИИ используется в виде чата. Это самый доступный и универсальный способ — просто копируешь кусок кода, задаёшь вопрос и получаешь ответ. Такой подход особенно хорошо работает, когда нужно быстро что-то объяснить, проверить, переписать или сгенерировать. Многие разработчики уже воспринимают ИИ-чат как обычный инструмент: как Stack Overflow, только без поиска и без 20 открытых вкладок.

Но у чата есть ограничение: он не видит проект целиком. Всё, что он знает, — это то, что вы добавили в промпт. Поэтому приходится давать контекст вручную, объяснять, где что находится и как устроено.

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

Агентский режим реализуется через ассистентов в редакторе, например, Copilot и интеграции через протокол MCP (Model Context Protocol). MCP позволяет подключать ИИ к реальным источникам данных — коду, документации, таск-трекерам, Google Docs, GitHub и другим. Вместо ручной вставки фрагментов, ИИ получает доступ к полному контексту и может давать более точные и полезные ответы.

Как это работает

В отличие от обычного чата, где ИИ получает только те данные, что вы вручную вставили в промпт, ассистенты с доступом к проекту работают иначе. У них есть возможность «видеть» код целиком и работать с ним как с живой системой. Это меняет сам процесс взаимодействия.

Такие ассистенты сами умеют находить связи в коде. Контекст для этого берётся сразу из нескольких источников: структуры папок, импортов и зависимостей, названий и комментариев в коде, конфигурационных файлов вроде package.json или pyproject.toml. На этой базе ассистент понимает, как части проекта связаны друг с другом: какие модули вызывают функцию, какие файлы отвечают за тесты, где лежат модели и конфигурации. Для чата без контекста это невозможно — он видит только то, что вы вставили вручную.

Здесь может помочь файл AGENTS.md. Это дополнительный гид для ассистента, где команда описывает ключевые детали: какие папки важны, как устроен проект, где лежат модули, какие правила и соглашения действуют в кодовой базе. Благодаря этому ассистент быстрее ориентируется и меньше спрашивает очевидные вещи. Такой файл играет ту же роль, что и README для разработчиков, но только для ИИ. Многие ассистенты могут генерировать его начальную версию на основе самостоятельного исследования кода.

Во-вторых, они умеют находить связи. Если вы задали вопрос про конкретную функцию, агент может сам проследить, откуда она вызывается, какие модули подключает, где лежат связанные тесты. Для чата без контекста это невозможно — он видит только то, что вы вставили.

Дальше идёт работа по шагам. Обычно ассистент:

1. Уточняет задачу у вас — спрашивает, чего именно вы хотите: исправить баг, улучшить стиль, добавить функциональность.
2. Сам переходит к нужным файлам и строкам — открывает исходники, находит конфигурации, читает комментарии.
3. Строит гипотезу и предлагает изменения. Иногда он покажет несколько вариантов и спросит, какой подходит.
4. Проверяет результат. Некоторые интеграции позволяют ассистенту запустить тесты, прогнать линтер или компиляцию, чтобы убедиться, что изменения рабочие.
5. Делает правки по кругу: если результат не соответствует ожиданиям или тесты падают, он может повторить цикл — внести изменения, снова проверить и так до тех пор, пока цель не будет достигнута или пока не упрётся в ограничение (например, закончится доступный контекст или станет нужна дополнительная информация от вас).

Здесь появляются режимы работы. Ассистент может действовать в автоматическом режиме — сам вносить правки, запускать тесты, коммитить изменения без лишних вопросов. Это удобно для мелких задач и рутинных исправлений. Другой вариант — работа с подтверждением: ассистент предлагает изменения, но ждёт вашего апрува перед их применением или запуском команды. Такой режим чаще используют для важных или потенциально рискованных операций.

Ассистент останавливается, когда задача выполнена (код скомпилировался, тесты прошли, структура соответствует описанию) или когда он понимает, что без уточнений от вас двигаться дальше невозможно. В этот момент он сообщает о достигнутом результате или задаёт вопрос, чтобы получить недостающие данные.

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

Работа с ожиданиями

Особенность цикла работы с ассистентом в том, что он двигается маленькими шагами. Он может исправить одну строку, проверить тесты, затем предложить следующую правку и ждать подтверждения. Такие итерации накапливаются и превращаются в череду мелких ожиданий: вы нажимаете «да», он делает шаг, снова ждёт, снова спрашивает.

Чтобы этот процесс не превращался в тормозящий фактор, важно управлять ожиданиями:

• Группировать задачи. Вместо серии мелких апрувов задавайте цель сразу на несколько шагов: «сделай правку, обнови тесты и проверь линтер». Ассистент выполнит всё за цикл, а вы проверите итог.
• Определять границы автоматизации. Рутинные операции (форматирование, фиксы в тестах, обновление зависимостей) можно доверять автоматическому режиму. Более значимые изменения — оставлять под ручной апрув.
• Чётко формулировать критерии завершения. Например: «считаем задачу выполненной, когда тесты зелёные и линтер без ошибок». Это помогает ассистенту остановиться вовремя и не зациклиться на дополнительных правках.

Такой подход снижает количество ненужных пауз и делает взаимодействие более предсказуемым: ассистент работает крупными блоками, а вы контролируете только важные точки, не отвлекаясь на каждую мелочь.

Безопасность и границы

При работе с ассистентом важно заранее определить рамки его возможностей. Даже если у него есть доступ к проекту через MCP, это не значит, что ему стоит доверять любые действия.

• Ограничение доступа. Ассистенту можно открыть только те директории, где он реально нужен: src/, tests/, docs/. Папки с инфраструктурой, конфигурацией CI/CD и секретами лучше закрыть.
• Команды под контролем. Запуск тестов, линтера или сборки можно автоматизировать. А вот миграции, деплой, изменение конфигураций или работу с базой данных — оставлять под ручной апрув.
• Работа с секретами. Ассистент не должен видеть реальные ключи и токены. Для проверки кода стоит использовать моки, переменные окружения-заглушки или тестовые сервисные аккаунты.
• Фиксация границ. Всё это можно описать в AGENTS.md: где ассистенту разрешено работать, какие команды доступны, что требует подтверждения, а что категорически запрещено.

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

Типичные задачи

ИИ умеет писать код на популярных языках, дописывать фрагменты, предлагать альтернативные решения, находить баги, помогать с тестами и объяснять, что делает тот или иной участок программы. Это делает его особенно полезным в повседневной разработке: когда нужно быстро вспомнить синтаксис, проверить идею или разобраться в чужом коде.

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

Напиши скрипт на Python, который читает CSV-файл и выводит уникальные значения из столбца "email". Без внешних библиотек.

Такой запрос даст готовое решение, с которым можно сразу работать. А если вы анализируете чужую инфраструктуру — например, конфигурацию nginx — можно задать уточняющий вопрос:

Вот конфигурация nginx. Объясни, что она делает, и укажи, есть ли в ней ошибки.

ИИ поможет разобрать конфиг по частям, пояснит назначение директив и подскажет, где могут быть проблемы.

Когда нужно выбрать между несколькими реализациями, ИИ может сыграть роль советника:

Вот два варианта функции. В чём отличия и какой лучше выбрать?

Это удобно, когда вы сомневаетесь между разными стилями, подходами или уровнями абстракции.

Тесты и автоматизация

Если вы работаете с автотестами, ИИ может помочь на старте. Например, по уже написанной функции он может сгенерировать базовые тесты:

Напиши юнит-тесты на эту функцию. Возьми пример отсюда path/to/test. Проверь граничные случаи.

Даже если тесты требуют доработки, это экономит время на рутине — особенно если нужно покрыть много однотипных сценариев. Также можно просить сгенерировать заглушки, фабрики, фикстуры или вспомогательные функции:

Создай мок-объект для API, возвращающий фиктивные данные

Пояснение незнакомого кода

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

Поясни, что делает эта функция. Какие у неё входные и выходные данные?

ИИ может разложить код на шаги, дать краткое описание логики, пояснить, как обрабатываются исключения, и на что обратить внимание.

Работа с регулярными выражениями

Регулярки — классика "чёрной магии". Даже опытные разработчики не всегда пишут их с нуля. ИИ помогает понять, что делает выражение, и адаптировать его под нужный кейс:

Объясни, что делает вот это регулярное выражение: ^\d{4}-\d{2}-\d{2}$

ИИ расшифрует: это шаблон даты в формате YYYY-MM-DD, проверяющий, что строка состоит из четырёх цифр, дефиса, двух цифр, дефиса и ещё двух цифр, без лишних символов.

Можно просить сгенерировать своё выражение:

Напиши regexp, который находит email-адреса с доменом example.com

Результат можно сразу протестировать или адаптировать под язык (JavaScript, Python, Go и т.д.).

Генерация SQL

При работе с базами ИИ помогает как на уровне запросов, так и при проектировании схем. Например:

Сгенерируй SQL-запрос, который выбирает всех пользователей с ролью 'admin' и последним входом не старше 30 дней

ИИ предложит корректный SELECT с WHERE и условием по дате. Можно и наоборот:

Создай таблицу orders с полями: id, user_id, status, total, created_at

ИИ сгенерирует CREATE TABLE с нужными типами данных, ключами и, возможно, индексами. Он умеет учитывать специфику PostgreSQL, MySQL и SQLite — это особенно полезно, если вы не помните синтаксис наизусть.

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

Документация и комментарии

Тут ИИ может серьёзно помочь — и сэкономить время, и повысить читаемость кода.

Можно попросить:

• Сгенерируй комментарии к этой функции
• Напиши docstring в формате Go / Python / JSDoc
• Объясни, что делает этот блок, в одном абзаце

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

Если подходить с умом, можно сразу просить:

Напиши README, объясняющее, что делает этот скрипт и как его запускать

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

Логи и ошибки

Когда в терминале появляется длинный трейс — не всегда понятно, где начинается проблема. Особенно если это стек из нескольких уровней: npm, какой-то loader, ваш код, библиотека. Или если лог большой, с кучей строк, дат и служебной информации.

TypeError: Cannot read properties of undefined (reading 'map')
    at transformData (/app/utils/transform.js:42:18)
    at /app/routes/data.js:17:19
    at Layer.handle [as handle_request] (/app/node_modules/express/lib/router/layer.js:95:5)
    at next (/app/node_modules/express/lib/router/route.js:144:13)

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

Можно также просить упростить лог, убрать шум и оставить только суть:

Перепиши лог так, чтобы было видно, что произошло и где искать проблему.

Это не отменяет необходимость в умении читать логи, но помогает быстрее сориентироваться, особенно в незнакомом проекте.

Copilot и друзья: ИИ, который пишет вместе с вами

Здесь мы рассмотрим несколько рекомендаций, по тому как использовать асистентов наиболее эффективно.

Автокомплит

Первый и самый очевидный режим — продолжение кода. Вы начинаете писать строку — он подхватывает. Пишете for item in — получаете целый цикл. Добавляете комментарий // validate email — появляется реализация функции. Это удобно, когда задача рутинная, и нет смысла тратить время на уже знакомые конструкции.

Но у ИИ-автокомплита есть особенность: он часто предлагает не один вариант, а сразу целую конструкцию — и это не всегда то, что ожидаешь. Вместо привычного автокомплита по словарю, который просто подставляет название функции или переменной, вы получаете кусок логики, который нужно прочитать, осмыслить и решить — подходит он или нет. Это требует больше внимания.

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

Генерация по описанию

Второй режим — генерация по описанию. Достаточно ввести комментарий вроде:

# Функция, которая принимает список и возвращает только уникальные значения

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

Объяснения и правки

Третий режим — объяснение и правки. Некоторые инструменты позволяют выделить участок кода и задать вопрос:

Объясни, что делает этот блок. Убери дублирование. Сделай код понятнее.

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

Такие помощники особенно хорошо работают в связке с комментариями. Даже короткая подсказка вроде // sort by timestamp даёт им достаточно контекста, чтобы предложить разумное решение. Они не всегда угадывают идеально, но часто попадают достаточно близко, чтобы не начинать с пустого листа.

Главное преимущество — меньше отвлечений. Вместо того чтобы переключаться в браузер, искать пример или вспоминать, как назывался нужный метод, можно остаться в потоке и двигаться дальше. Это не про магию, а про экономию внимания.

Переработка кода по аналогии

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

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

Устаревшие версии и решения

Одна из частых проблем при работе с ИИ — устаревшие примеры. Модель может предложить синтаксис, который уже не работает в вашей версии языка или библиотеки: старую структуру package.json, неактуальные опции конфигурации, методы, которые были удалены, или даже библиотеки, которые больше не поддерживаются. Это особенно заметно в динамичных экосистемах вроде React, Next.js, TypeScript или инструментов DevOps.

Это не делает ИИ бесполезным, но важно помнить: у модели нет встроенного доступа к «свежести» технологий, если её специально не подключить к вашему проекту. Поэтому предложенный код всегда стоит проверять.

Что с этим делать:

• Сравнивать ответы с официальной документацией. ИИ может ускорить поиск решения, но не заменяет документацию.

• Уточнять версии прямо в запросе:

  Покажи пример для React 18 Как это делается в TypeScript 5.3?

• Проверять код на актуальность перед использованием, особенно если заметили несоответствие с привычным синтаксисом.

Ситуация заметно улучшается при использовании инструментов с поддержкой MCP (Model Context Protocol). В этом режиме ассистент получает доступ к вашим файлам конфигурации — package.json, requirements.txt, pyproject.toml, go.mod и другим. Благодаря этому он знает, какие именно версии библиотек и фреймворков используются в проекте, и может подбирать примеры кода с учётом этой информации.

Хотя MCP даёт ассистенту доступ к документации и исходному коду библиотек, у него всё равно нет «большой выборки» живых примеров использования. Это значит, что по API он может составить корректный вызов функций и методов, но предложенный сценарий применения не всегда будет лучшим или распространённым в сообществе. Ассистент знает, как работает метод, но не всегда — как им реально пользуются в типовых задачах. Поэтому такие ответы стоит сверять с практикой, искать реальные примеры в официальных гайдах или репозиториях.

Таким образом, MCP снижает риск получить устаревшее решение и делает взаимодействие с ИИ более надёжным: он ориентируется не только на общие знания, но и на конкретный контекст вашего проекта. Но окончательную проверку на соответствие best practices всё ещё лучше делать вручную.